While I'm a big fan of haproxy, Apache, and nginx, I will say I also very much like trafficserver as a cache. Compared to squid, which I've always wanted to like but never really have, it is much easier to set up, and it's proven to be very reliable in our use.

Specifically, I install it, point it at a large raw disk partition, and drop in my config files (largely consisting of routing rules for where to get the origin based on the request), and trafficserver just goes to town. It's a perfect use case for the ephemeral storage on virtual instances.

Although haproxy and nginx cover (for me) almost all use-cases I had to deal with (with OpenResty [1] as a backup), I see one place where ATS could shine: plugins. From examples [2], C API looks sane and well documented, and this is very important if you want to add some custom stuff inside your proxy server without losing your hair. And no, lua isn't the solution here ;)

Those who had to deal with nginx plugins, I feel your pain...

[1] https://openresty.org/en/

[2] https://github.com/apache/trafficserver/tree/master/example/...

> And no, lua isn't the solution here

why wouldn't Lua be a solution here?

Too slow for a proxy cache of ATS's caliber/audience.

I find that hard to believe. As far as I know, Nginx/Lua/LuaJIT still powers almost all of CloudFlares edge services.

[1] https://blog.cloudflare.com/pushing-nginx-to-its-limit-with-...

[2] https://blog.cloudflare.com/cloudflares-new-waf-compiling-to...

As I understand it, Cloudflare’s major use of LuaJIT was for their WAF, and they have recently rewritten it in Rust https://blog.cloudflare.com/new-cloudflare-waf/

If YouTube finally off Python? ;)

"And no, lua isn't the solution here ;)"

openresty is (patched) nginx + luajit

haproxy has optional extension with lua as well

CMIIAW, what parent is saying is he does not like lua for this purpose

trafficserver also has a compile-time option "--with-luajit"

one of the nice things about haproxy is that pcre is optional. it seems pcre is a hard requirement to compile trafficserver

trafficserver is also much more code, coming from a variety of sources.

Lots of choices in the this space...

  - this tool (apache traffic server)
  - regular apache can proxy/cache/route
  - nginx
  - traefik
  - haproxy
  - envoy
  - kong
  - ...more

Then it also somewhat intersects with less directly related things in other spaces, like squid, varnish, istio, and so on.

Is there some document somewhere that goes over the choices, overlaps, etc?

Why do you describe it as less directly related to squid and varnish? I haven't worked with ATS before, but it's documentation describes it as "a high-performance web proxy cache that improves network efficiency and performance by caching frequently-accessed information at the edge of the network" which makes it seem to fill a similar role as them.

Yes, you're right, though that sort of goes to my question :)

Istio is primarily just a wrapper around Envoy, no?

Which of those can proxy TCP, as opposed to HTTP? Haproxy can.

nginx too http://nginx.org/en/docs/stream/ngx_stream_proxy_module.html

Traefik too.

Varnish?

> Is there some document somewhere that goes over the choices, overlaps, etc?

I believe Apache Traffic Server doesn't really compete with the likes of nginx or traefik. Apache Traffic Server is a HTTP caching server/web accelerator, thus it's specialized for caching HTTP requests and consequently it's simpler to deploy and configure. With that in mind, it competes with the likes of Squid[1] or Varnish[2].

[1] http://www.squid-cache.org/

[2] https://varnish-cache.org/

It does support routing via SNI. And of course, people do use nginx (and other tools) just as proxy caches. That's sort of what I was getting at, lots of overlap and sub-niches.

I've used varnish in the past with cdn's, never had an issue so I have not tried other cashing/load balancing products.

Internally use squid with rules for non routed internal network addresses.

Sounds like lots of newer products out there, maybe even better products, but you sometimes just stay with whats working due to time/budgets.

Would really be interested in articles with benchmarks, pros/cons, etc on different products. Wonder why not many websites doing this for content? Sounds like a good market that needs filled.

Almost everyone is an end user of Apache Traffic Server without really knowing it. It is used by Yahoo, Apple, Comcast, Wikipedia, AT&T, Cox and many other companies.

Some companies that use it at very large scale don't like to talk about what technologies they use.

Yup LinkedIn and Apple uses it very extensively. So is Yahoo.

Been to many ATS meetups, even worked on atscppapi years ago. Very robust plugin capabilities.

Oh, this brought back a lot of good memory in Yahoo. This thing was originally called YTS, it has a very flexible plugin system, the caching functionality was pretty good and easy to use at the time.

AFAIK Netlify uses Apache Traffic Server for their 'CDN'

(Vercel uses nginx)

Discussion in 2016 [0]

My impression from the comments is, that at least back then, it could be faster than things like Nginx or Varnish

[0]: https://news.ycombinator.com/item?id=10983331

Subject should be changed to "Apache Traffic Server Security Fixes" or similar.

Looks like the "News" is that Nov 2 they released 8.1.3 and 9.1.1 with "security fixes". However, after digging for half an hour I can't tell what the nature of the security fix is. Changelogs and issues related to these releases don't highlight any particular security issues or what the impacts are.

> Subject should be changed to "Apache Traffic Server Security Fixes" or similar.

I submitted the link before the new release with security fixes was announced, without that in mind. Moreover, the link points to the project page and not the release. I submitted because I found the project interesting but somewhat low-key, and I thought people like me would find it interesting.

Fair enough, but I stand by that the news is that there's a security fix.

Yes, I agree. Happy accident and all.

Looks recent, at first I thought it was webserver from the 90's...

This was originally “Yahoo! Traffic Server”, was developed by Yahoo! in the early 2000’s and was used in part to power Yahoo! CDN. At the time Yahoo! relied on Akamai and its own network.

It was developed by inktomi[1]; inktomi was acquired by yahoo in the one of the great extinction events of the early internet.

[1]https://en.wikipedia.org/wiki/Inktomi

I kinda forgot the Traffic Server existed. I remember we looked at it 10 years ago for a project, but just went with nginx instead. I don't think we ever really saw the point in Traffic Server, and I still don't. That might just be because it solves a set of problems I don't deal with.

Not sure if this is what you're thinking of, but to be clear, this isn't the Apache web server (aka apache httpd or apache2).

> Looks recent, at first I thought it was webserver from the 90's...

Well, old ideas are indeed new once everyone forgets they were a thing. Nowadays CDNs and edge caches and web accelerators are seeing a resurgence, and in practice they can mean having an instance of Apache Traffic Server deployed somewhere.

Anyone know how it might compare to Neflix Zuul

Zuul is a proxy not a caching proxy IIRC.