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?
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 getting refreshed, will get the stale version tho).
It's the difference between your client being amazed by how fast your api is, to "wtf does page X takes 3s to render from time to time" comments.
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.
* 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.
A one or two orders of magnitude greater speed, lots of configurations for caching policies, the ability to split a request in several subrequests (ESI) and some other nice things.
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.
So the conclusion is, as long your malloc fits in your system memory, Varnish should be blazing fast on Linux. If you need a gigantic cache, please try FreeBSD.
I don't suppose that particular workload was very suited for Varnish in the first place, if you read carefully, you'll soon realize that most people don't have that kind of content.
I have heard from (other parts of) BBC that Varnish saved a fair amount of bacon for them during the London Olympics, obviously in different workloads.
And nobody would be more surprised than me, if Varnish was a micacle-cure for every single website in the world...
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 release notes http://varnish.org/docs/5.0/whats-new/relnote-5.0.html "It is important that people understand that Free and Open Source Software isn't the same as gratis software: Somebody has to pay the developers mortgages and student loans."
Varnish is an excellent piece of software, but I thought it was totally funded by the commercial side varnish software. How does this model work? It seems odd to ask for donations while also selling an expensive supported version?
The Varnish Cache FOSS project and Varnish Software the company are two entirely different things.
By and large, the Varnish Cache FOSS project is me, and I am not employed by Varnish Software: I have my own one-man company where I "make computers to do weird things".
The time I spend on Varnish Cache is funded by "The Varnish Moral License":
Varnish Software is one of the handful of companies who pay via the VML to keep me working on Varnish.
Varnish Software has also supported the project in many other ways as well, from running the project server to donating manpower and source code.
Some of these things are being scaled down, for instance the project server had become the square peg in their round internal IT systems, so I have been migrating that off to a server kindly sponsored by RootBSD.
"Until now Varnish Software has done a lot of work for the Varnish Cache project, but for totally valid reasons, they are scaling that back and the project either needs to pick up the slack or drop some of those activities."
Why they are pulling back is anybody's guess. But it sounds like they are focusing on monetizing the existing codebase instead of further developing it.
[+] [-] tomschlick|9 years ago|reply
[+] [-] zcam|9 years ago|reply
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 getting refreshed, will get the stale version tho).
It's the difference between your client being amazed by how fast your api is, to "wtf does page X takes 3s to render from time to time" comments.
[+] [-] mwpmaybe|9 years ago|reply
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.
[+] [-] jacquesm|9 years ago|reply
https://www.varnish-cache.org/trac/wiki/ArchitectureInlineC
[+] [-] buro9|9 years ago|reply
* 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.
[+] [-] corecoder|9 years ago|reply
[+] [-] c0l0|9 years ago|reply
In terms of introspectability, Varnish (afaik) is without equal.
[+] [-] sdca|9 years ago|reply
[+] [-] jimjag|9 years ago|reply
2: More control.
3: Better compliance
[+] [-] hannob|9 years ago|reply
[+] [-] phkamp|9 years ago|reply
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.
[+] [-] ruben_varnish|9 years ago|reply
Made by Varnish Software to provide a "browser-vendor-compliant" HTTP/2 stack.
[+] [-] vertex-four|9 years ago|reply
[+] [-] flojo|9 years ago|reply
In the BBC’s testing, they found that with NGINX as a drop-in replacement for Varnish, they saw five times more throughput.
[+] [-] olavgg|9 years ago|reply
https://news.ycombinator.com/item?id=10752209
So the conclusion is, as long your malloc fits in your system memory, Varnish should be blazing fast on Linux. If you need a gigantic cache, please try FreeBSD.
[+] [-] phkamp|9 years ago|reply
I have heard from (other parts of) BBC that Varnish saved a fair amount of bacon for them during the London Olympics, obviously in different workloads.
And nobody would be more surprised than me, if Varnish was a micacle-cure for every single website in the world...
[+] [-] cheald|9 years ago|reply
[+] [-] willvarfar|9 years ago|reply
Of course he relented and implemented SPDY and HTTP/2 anyway.
But all the same I can't help but feel that his original criticsm still stands, and what we need is a rethink of e.g. cookies.
[+] [-] youngtaff|9 years ago|reply
From my reading PHK didn't think it went far enough, and wanted to change more.
I think he's got good points to make on session ids, cookies etc. and I suspect we'll se some of the ideas feed into future versions too.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] jjoe|9 years ago|reply
Anyway, I'm looking forward to testing it out and integrating v5 with Cachoid ( shameful plug: https://www.cachoid.com/ ).
[+] [-] ksherlock|9 years ago|reply
> 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).
[+] [-] boyter|9 years ago|reply
Varnish is an excellent piece of software, but I thought it was totally funded by the commercial side varnish software. How does this model work? It seems odd to ask for donations while also selling an expensive supported version?
[+] [-] phkamp|9 years ago|reply
The Varnish Cache FOSS project and Varnish Software the company are two entirely different things.
By and large, the Varnish Cache FOSS project is me, and I am not employed by Varnish Software: I have my own one-man company where I "make computers to do weird things".
The time I spend on Varnish Cache is funded by "The Varnish Moral License":
http://phk.freebsd.dk/VML/index.html
(See also: http://queue.acm.org/detail.cfm?id=2636165)
Varnish Software is one of the handful of companies who pay via the VML to keep me working on Varnish.
Varnish Software has also supported the project in many other ways as well, from running the project server to donating manpower and source code.
Some of these things are being scaled down, for instance the project server had become the square peg in their round internal IT systems, so I have been migrating that off to a server kindly sponsored by RootBSD.
[+] [-] qeternity|9 years ago|reply
Why they are pulling back is anybody's guess. But it sounds like they are focusing on monetizing the existing codebase instead of further developing it.