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

http://www.slideshare.net/thenickberry/reflecting-a-year-after-migrating-to-apache-traffic-server

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.

I've started adding some notes about ATS to wikitech: https://wikitech.wikimedia.org/wiki/Apache_Traffic_Server.