[latch]

My experience with Varnish was when we tried to use it for something that had relatively complex caching rules. The config/VCL became spaghetti: attaching values to req and restarting the flow. This appeared to be the normal way to write VCL.

We ended up writing our own system, with our own high-concurrent LRU cache, that was more tightly coupled with our application servers (and thus able to figure out what the cache key should be). It ended up being trivial to then add things like ESI, purging, grace and saint mode.

Point being, since then, I've had a hard time seeing where Varnish fits between proxy_cache for simple url+query caching, and rolling your own.

[bkeroack]

Agreed. Varnish is great if you have an existing web application that needs a quick-and-dirty caching layer built in front of it.

Varnish gives you enough configurability to do just about anything, but the end result will be a spaghetti mess of VCL, inline C and possibly custom varnish modules. The more sustainable route is to build your own caching front end, however I think it's a bit unrealistic to assume that all startups have the engineering talent (or time) in-house to implement that sort of thing.

[spacemanmatt]

Wow, this (and parent-post) really colors my understanding about how far one can/should go with Varnish before building something more tailored. Thanks.

[ruben_varnish]

I think your description might fit if performance and scalability is a non-issue for your site.

Your own caching will make your webapp (or API) scale (say 2x faster or serve 15x the amount of users), but if you need your app to take some serious beating (say 100x to 400x the amount of users with minimal ttfb) because your site/app suddenly becomes flavour of the month on the Internet, then you will really need Varnish.

After seeing several Paywall and API deployments and all sorts of other advanced business logic, such as GeoIP detection or Mobile device classification, applied in the cache layer while keeping a sane and simple VCL, I am not sure your initial point is the case. The normal way to write VCL is to keep it simple.

(Yes, I am biased, but my point is still valid).

[latch]

We were handling over 10K req / sec through that layer of our system and load tested the entire system to over 100K, testing various cache hit ratios (our 95th percentile uncached response time was ~5ms for our core service). At that scale, a sudden 400x spike isn't something you worry about -- our various network providers would null route us way before we ever got there.

When we moved away from Varnish towards our own integrate cache, our hit ratio went from 50% to 80% on average, and some individual routes hit over 95% (we proactively purged+refetched in the background through a queue).

So maybe you're right, but for the opposite reason that you state. Our scale and performance requirements were so great, a custom solution made more sense.

[ruben_varnish]

I think that the point with Varnish and VCL is that you can adapt it, tailor it and even extend it (the language with additional functionality from external libraries i.e. cURL or memcached) to the point that it fits your system just the way you need it.

Obviously, depending on what you were trying to do and to which extend Varnish was extendable then (VMODs were added in 3.0) it might not have been the best option there is.

Anyway, thank you for your reply. It was a very interesting insight you came with there.