Varnish Cache 5.0

There is quite a few places for improvement in that test (e.g. tweaking number of threads in Varnish) and by no means the tests are like for like.

I will take it with a grain of salt or do your own tests, if you really care.

I don't think your experience alone is enough to say whether performance differences are significant or not.

While in your experience the performance differences were negligible, but that doesn't mean that will hold true in all usage scenarios. For example, maybe they perform similarly when caching many small files, but one struggles with serving longer running requests.

I'm sorry but I strongly disagree with the line of thought there.

Parent above was saying "both are at the same speed / none offer any speed advantage".

He is then asked for any metrics to support that statement, which is not an extravagant request and should be encouraged more.

Your answer that "At that point, talking about metrics is likely procrastination" and "one will be faster than the other in any given scenario" serves nothing other that further his statement while deriding the need for said metrics to prove that this is not turning anecdotal evidence into facts, and frankly serves nothing to the discussion short of saying the point should be accepted without verification and that asking for verification is useless.

A point of view I really cannot agree with. I do not know which is faster, nor if any of them is faster than the other or not, but if somebody claims one way or the other in a factual manner, he should not find it a waste of time to find an actual metric that shows it.

If you're already using Nginx and its caching subsystem is working for your use case(s), then I wouldn't worry about it. A typical web stack is composed of load balancing, SSL termination, caching and compression, and static and dynamic content serving. Nginx is capable of all these things (including dynamic content serving using OpenResty).

Once you start breaking your stack apart to 1) add redundancy, 2) isolate hardware for different workloads, and 3) scale the components independently of each other, the situation gets a little more interesting. Sure, you could run different clusters of Nginx for each of SSL termination, static content, cache and compress, etc. and have them reverse proxy to each other (and some people probably do this), but when you get to this evolution of your architecture, it's worth evaluating the different options for each layer of the stack. There's an argument to be made that e.g. HAProxy is a better load balancer, Nginx is a better static content server, Pound is a better SSL terminator, Varnish is a better caching and compressing reverse proxy, etc. (N.B. that I am not saying these things, I am just saying that they can be said.) If you're not serving static content at all—let's say you're presenting an API written in Elixir/Phoenix—it may not make sense to go with Nginx in the first place!

Regarding Varnish, specifically, I've found that it offers unparalleled power and flexibility when it comes to caching and compression. Yes, that power and flexibility comes at the cost of more complexity, but it's there when you need it. It offers different storage backends, including a pure memory backend; the ability to serve gzipped content directly from cache (for supported clients); PURGE and BAN HTTP verbs; synthetic responses; query string sorting; the ability to serve stale content while updating; ESI; and probably a whole bunch of other stuff I'm forgetting and/or have never used. Nginx and Nginx Plus may support some or all of these things, built-in or as modules... I'm not sure.

For caches much larger than available memory nginx will win because it caches to static files and uses sendfile:

http://www.bbc.co.uk/blogs/internet/entries/17d22fb8-cea2-49...