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 irc.freenode.net, here's a bunch of links with some useful information:

http://incubator.apache.org/projects/trafficserver.html

http://cwiki.apache.org/confluence/display/TS/Index

http://svn.apache.org/repos/asf/incubator/trafficserver/

http://incubator.apache.org/trafficserver/docs/admin/

http://incubator.apache.org/trafficserver/docs/sdk/

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 thoughs on TS.

Performance

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
"map http://www.foo.com/ http://www.foo.com/"
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.

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 :).

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.

Cheers

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Sponsors

Powered by Drupal, an open source content management system