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...
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.
> 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].
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.
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.
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.
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.
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.
> 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.
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.