mnot’s blog

Design depends largely on constraints.” — Charles Eames

Friday, 30 October 2009

Traffic Server

A long time ago*, the word in high-performance proxy-caching was Inktomi’s Traffic Server. It was so fast it was referred to being “carrier grade” and this could be said without people smirking, and it was deployed by the likes of AOL, when AOL was still how most people accessed the Internet.

Then, in 2001, Yahoo! bought Inktomi. They did this because they wanted to be a player in Search, and they happened to get a proxy/caching product for free. It promptly went on the shelf, to be forgotten by all (except the original engineers, a few customers, and the company that support was contracted out to).

A few years ago, some Yahoo! engineers found that code sitting on a shelf and decided to have a play. What they found was that it was still faster than pretty much every thing else out there. So they started using it, and built a team around it.

Fast forward to today, when the source code for Traffic Server is suddenly available as an Apache Incubator Project.

I’m sure you’ll be hearing more about it from its developers (I’m just a bystander, relatively), but from my point of view, this is only goodness; another general-purpose high-performance HTTP proxy/cache implementation is sorely needed, for reasons I’ve discussed before.

So take a look at the source, have a play with it, and come to the MeetUp at ApacheCon next week to see where this thing is going.

* Not a long, long time ago, when the word in proxy/caching was Harvest, the granddaddy of them all. But that’s another story.

Update: Leif (one of the core developers) gives his take.

Filed under: Caching HTTP Web


Blair Zajac said:

Hey Mark,

Very cool stuff.

Have you seen any of the performance comparisons? We may be switching from an NFS to a HTTP serving infrastructure for WAN connections (fronted by FUSE), so having a good caching infrastructure is key.


Saturday, October 31 2009 at 10:54 AM +10:00

Mark Nottingham said:

Hey Blair,

Perf depends very much on both the hardware and workload. On modern hardware (e.g., 8-core) with a high hit rate workload, it can easily saturate a gigabit, and do 30-50,000 req/second, depending on the details.

Sunday, November 1 2009 at 9:25 AM +10:00

Leif Hedstrom said:

In a no-cache setup (proxy only), it can do in the order of 10-20K QPS, depending on things like HW, object size, keep-alive (or not) etc. The most I've clocked it without KA was about 16k connections / sec (which translates to accepting 16k conns, and creating 16k conns). But, it'll be really interesting to see new sets of benchmarks on different kernels, distros and HW.

Sunday, November 1 2009 at 3:03 PM +10:00

David Hattersley said:

Hi Mark,

I am really interesting in hearing about TrafficServer, but I am not sure I can make it on Tuesday. Is there any chance that the session will be posted online after the event.



Tuesday, November 3 2009 at 11:35 AM +10:00

Carlos Perez said:


I had thought that Yahoo employed Squid for its reverse proxy caching. So is TrafficServer used in just a few places at Yahoo or is it everywhere?

Tuesday, November 3 2009 at 5:32 PM +10:00

stan said:

I been using TS since it go open source. I set it up as my forward proxy and reverse proxy. I have WAN optimize in front and TS behind it, and the performance and it caching speed is amazing! And the best part is, it support dynamic page caching :D


Tuesday, January 19 2010 at 2:05 PM +10:00

Creative Commons