Page MenuHomePhabricator

Evaluate Apache Traffic Server
Closed, ResolvedPublic

Description

Evaluate whether Apache Traffic Server could be a useful replacement for varnish. This is still at the early stages and needs basic research before even working on actual software testing.

Event Timeline

BBlack raised the priority of this task from to Low.
BBlack updated the task description. (Show Details)
BBlack added projects: acl*sre-team, Traffic.
BBlack added a subscriber: BBlack.
BBlack raised the priority of this task from Low to Medium.Apr 28 2015, 12:14 PM
BBlack set Security to None.

"comparision: Serving small static files with Nginx, Varnish, G-WAN, Lighthttpd, Apache Traffic Server"

"G-WAN seems again to perform a lot better than the other servers. Nginx always performs slightly better than Lighttpd, while Apache Traffic server is very similar to Lighttpd in term of performance. Finally, Varnish Cache serves only half of the requests compared to all others. "

https://x443.wordpress.com/2012/07/07/comparision-serving-small-static-files-with-nginx-varnish-g-wan-lighthttpd-apache-traffic-server/

Is that still planned now that we're moving to varnish 4?

Yes. We decided the varnish 4 migration was the next necessary practical step regardless, but I think at least evaluating other alternatives (which are more open-source-friendly, privacy-friendly, and possibly more-flexible) is still on the long-term radar, when we reach it in the priority stack.

In the most-recent discussions about this, I've been liking the idea of breaking this down into frontend and backend caching.

Frontend is heavy-traffic and high-complexity (in VCL/vmod terms). Backend is more or less just transitive generic caching and chashing with relatively-low traffic rates. Especially if ATS is better at things like persistent storage and efficient side-checks to other backends (and it seems to be, at a glance), the best effort-to-reward ratio probably lies in putting ATS in as a varnish-backend replacement, while leaving our varnish-frontends as-is on Varnish.

There might be interop downsides anywhere they disagree on HTTP protocol subtleties, but on the other hand there's resilience upsides to not having the front and back layers potentially subject to the same deadly bugs or attacks, too.

ema claimed this task.

This can be closed now that we have: deployed two test clusters running ATS and routing traffic to all our applications, gained basic operational experience with it, verified that with PURGE traffic peaks of 12K requests per second, resource usage stays reasonable.

ats-purge-operations-per-second.png (1×1 px, 157 KB)
ats-resource-usage.png (1×1 px, 261 KB)

So yes, ATS is a useful replacement for Varnish.