Traffic Server is finally here

Finally! We pushed the Traffic Server code to Apache SVN today! This is definitely a momentous occasion, this has been in the works for ages, and it took a lot of work and patience to happen. You wonder, why did we bother? Well, you are right, there's plenty of proxy server alternatives out there, Squid, Varnish, NginX and so on. But, we think we have a platform we can build something on that will be better than anything out there (that is free at least). Why? Well, we have

  • A scalable threaded + asynchronous state machine model. On a typical setup, 2 or 3 threads per core is enough to drive a large amount of traffic.
  • Feature-rich HTTP/1.0 and HTTP/1.1 support. We fair well in various tests like CoAdvisor.
  • Plugin architecture, making it easy (well, easier) to extend and customize your server.
  • Well documented.

I'm not saying it's perfect (far from it), but the hope is that Open Sourcing this will attract an active developer and user community around the software. So, you want more information? Well, besides visiting us on #traffic-server on, here's a bunch of links with some useful information:

Please join the mailing lists (see the Incubator page), talk to us on IRC, or just take a look at the code.

Update: Mark Nottingham (on our team now!) has a blog post with some interesting history and thoughts on TS.



Traffic Server w00t!

I can't imagine how long it took to get this added to the svn, well done. Hope to make use of it.


control port!

what about the control port! ;) i havent had a chance to look, but i heard it was removed- it was a nice way to pull metrics out :D

Re: control port

It'll be there, it's part of the traffic_manager process, which needs to start the traffic_server process (and restart it too if necessary). Our start script is just too primitive (and actually not functional) to deal with this yet.

For sure we'll need to support the control port :).


I ran a quick test on my shitty desktop at home (it's 4+ years old, 2 cores at 2.4GHz):

471780 fetches on 43504 conns, 1201 max parallel, 2.40007e+08 bytes, in 30 seconds
508.726 mean bytes/fetch
15726 fetches/sec, 8.00022e+06 bytes/sec
msecs/connect: 0.399028 mean, 23.133 max, 0.025 min
msecs/first-response: 11.6233 mean, 351.454 max, 0.014 min
HTTP response codes:
  code 200 -- 471526

~16k QPS with some keep-alive (10 req / connection), and a very small object. But, like I said, it's a slow machine, and we got tons of things we'll improve in TS :).

about remap.config

Thanks. when setup reverse proxy,if set CONFIG proxy.config.url_remap.remap_required INT 0, traffic server respond info "ERROR 404: Not Found on Accelerator.".
when set CONFIG proxy.config.url_remap.remap_required INT 1 , and add follow to remap.config
It's OK.

Please help me.

Re: about remap.config

Yeah, in reverse proxy mode, you must have a remap.config mapping rule, that configuration setting doesn't change that. What remap.remap_required=0 does is to allow you to function as a generic forward proxy, which is a slightly different format on the requests. We have things set to by default be as a reverse proxy only, with no remap.config, to avoid people accidentally setting up open proxies.



This looks great, I was just

This looks great, I was just reading the stats on this thing here, very impressive!

Apache traffic server installation in fedora

I am pretty much new to apache traffic server.
I like to install ATS in me fedora machine.
Please let me know what are all the installables required to install apache traffic server in the fedora machine.
And some installation procedure to do the set up.

I can't imagine how long it

I can't imagine how long it took to get this added to the svn, well done. Hope to make use of it. Cheers, Michel