Live data from Hacker News

Varnish Cache 5.0

varnish.org

21–30 of 55 posts

Re: Varnish Cache 5.0

#21
post #16

Earlier quoted context omitted.

If you use it for caching, nginx is lacking something quite important at the moment: stale-while-revalidate ( https://tools.ietf.org/html/rfc5861 ) Aka serving a cached response while the cache is getting refreshed (even to the request who initiated the refresh). Currently when nginx has to refresh the cache it will "hang" the current response until it gets refreshed (the requests that follow, even while the cache is…

I think "proxy_cache_use_stale updating;" covers this case

Nope: "updating" does what I described, if another request initiated an update and it's in progress, it will serve a stale value, but the request who triggered the update is still "hanging" until the cache is refreshed. So you get that annoying slowdown for at least 1 user (often the CEO of your client company).

The way to work around this issue with nginx (for simple endpoints) is to write scripts that will hit the endpoints to make sure the cache is always hot, but it's a sad, half working hack (the CEO can still hit that cold cache page himself, if lucky enough).

Re: Varnish Cache 5.0

#22
post #10

Do I understand this right? It supports HTTP/2, but doesn't support HTTPS. Therefore it supports HTTP/2 in a mostly unusable form, because browser vendors (for good reasons) decided to support HTTP/2 only over HTTPS.

The reason I don't want to link Varnish against a SSL library, is that in my considered opinion, they all suck.

From a purely operational point of view, you are better of with two different SSL proxies in front if your Varnish (or other webserver), so that you can turn OpenSSL off in even-numbered weeks and the other (pick your poison) in odd-numbered weeks.

The code to hold safely onto your certificate and do all the songs and dances involved in SSL/TLS, is under all circumstances something which should be isolated in as small a process/protection domain as possible.

Re: Varnish Cache 5.0

#23

As someone who has never used Varnish but has used Nginx's cache to some degree... whats the benefit of placing varnish in the middle vs going with Nginx?

* ESI support is really nice (if you're an API designer, you can really go nuts on this and make a super simple API do some very complex things or expressive composition from lots of simple calls)

* More fine-grained control of your caching is possible

* Easier to express normalisation of requests (increase your cache hit rate and protect your underlying origin from malicious requests by discarding cache busters)

* Inline C means you can do things like move your authentication to the edge

* In theory if you have enough RAM you can go faster than nginx's on-disk... in practice the sweet spot for the gain is small and they're both on par

But then... it comes with disadvantages too. Like most Varnish services would never let you do the nice Inline C stuff because no-one in their right mind would run untrusted code in their environment where it could impact another customer. If you see a provider do this (at any price point), avoid them.

Re: Varnish Cache 5.0

#24
post #23

As someone who has never used Varnish but has used Nginx's cache to some degree... whats the benefit of placing varnish in the middle vs going with Nginx?

* ESI support is really nice (if you're an API designer, you can really go nuts on this and make a super simple API do some very complex things or expressive composition from lots of simple calls) * More fine-grained control of your caching is possible * Easier to express normalisation of requests (increase your cache hit rate and protect your underlying origin from malicious requests by discarding cache busters) * I…

Since 3.0 you have VMODs, to counter for the well-founded lack of Inline C support around. These Varnish modules will extend VCL with C, C++ or even Rust libraries on a safer manner: https://varnish-cache.org/vmods/

If you make your own VMOD(can take from a few hours to days), make sure to send a PR and add it to the directory above (IOW: share it) :)

Re: Varnish Cache 5.0

#25

As someone who has never used Varnish but has used Nginx's cache to some degree... whats the benefit of placing varnish in the middle vs going with Nginx?

Take a look at `varnishlog` while you have traffic flowing thru - you'll feel like you've seen the light :) Also, read the vsl-query docs: https://www.varnish-cache.org/docs/trunk/reference/vsl-query...

In terms of introspectability, Varnish (afaik) is without equal.

Re: Varnish Cache 5.0

#26
post #25

As someone who has never used Varnish but has used Nginx's cache to some degree... whats the benefit of placing varnish in the middle vs going with Nginx?

Take a look at `varnishlog` while you have traffic flowing thru - you'll feel like you've seen the light :) Also, read the vsl-query docs: https://www.varnish-cache.org/docs/trunk/reference/vsl-query... In terms of introspectability, Varnish (afaik) is without equal.

Totally agreed!

I believe that the power and utility of VSL are so underestimated and overlooked that I don't know where to start...

Re: Varnish Cache 5.0

#27
post #7

It's always good to see new stuff coming out for Varnish. Do these changes warrant a major jump in release numbers especially when HTTP/2 support (biggest feature) is experimental? Anyway, I'm looking forward to testing it out and integrating v5 with Cachoid ( shameful plug: https://www.cachoid.com/ ).

From the horse's mouth:

> Varnish 5.0 changes some (mostly) internal APIs and adds some major new features over Varnish 4.1.

> We are in the process of adding HTTP/2 support to Varnish ... we hope to have it production ready for the next major release (2017-03-15).

Re: Varnish Cache 5.0

#28
post #23

As someone who has never used Varnish but has used Nginx's cache to some degree... whats the benefit of placing varnish in the middle vs going with Nginx?

* ESI support is really nice (if you're an API designer, you can really go nuts on this and make a super simple API do some very complex things or expressive composition from lots of simple calls) * More fine-grained control of your caching is possible * Easier to express normalisation of requests (increase your cache hit rate and protect your underlying origin from malicious requests by discarding cache busters) * I…

Thanks for the detailed list! ESI looks pretty sweet so I'll have to take a look at that as we scale out our API in the coming months.

Re: Varnish Cache 5.0

#29
post #19
post #15

Earlier quoted context omitted.

Faster in theory maybe. In production nginx has always faster, more stable, less resources. I've used both extensively. Varnish has more caching features and configuration for sure.

Out of interest, do you have any metrics to support this? It would be interesting to see data that compares the two, and see how close they come in different scenarios, and how tuning/configuration might affect the performance.

I've used both in production. They both fast enough that their performance won't be your bottleneck. One's probably faster than the other by some percentage, but whatever you do, you're going to have some other problem that's bigger than that percentage.

At that point, talking about metrics is likely procrastination.

Re: Varnish Cache 5.0

#30

As someone who has never used Varnish but has used Nginx's cache to some degree... whats the benefit of placing varnish in the middle vs going with Nginx?

The ability to manually purge the cache by URL, with wildcards, is pretty handy.
Post reply on HN