Page MenuHomePhabricator

Evaluate Apache Traffic Server
Closed, ResolvedPublic


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 created this task.Apr 22 2015, 2:19 PM
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.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 22 2015, 2:19 PM
BBlack raised the priority of this task from Low to Medium.Apr 28 2015, 12:14 PM
BBlack set Security to None.
Dzahn added a subscriber: Dzahn.EditedAug 11 2015, 12:51 AM

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

Restricted Application added a subscriber: Matanya. · View Herald TranscriptAug 11 2015, 12:51 AM
elukey added a subscriber: elukey.Feb 1 2016, 7:09 PM

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.

Peter added a subscriber: Peter.Sep 12 2016, 9:13 AM
ema added a subscriber: ema.Sep 27 2016, 8:46 AM
BBlack moved this task from Triage to Caching on the Traffic board.Sep 30 2016, 2:56 PM
ema added a comment.Jan 19 2017, 1:27 AM

I've started adding some notes about ATS to wikitech:

ema closed this task as Resolved.Sep 11 2018, 8:53 AM
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.

So yes, ATS is a useful replacement for Varnish.