11–20 of 55 posts
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.
Made by Varnish Software to provide a "browser-vendor-compliant" HTTP/2 stack.
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.
Historically, PHK was a very vocal criticizer of SPDY and HTTP/2: http://www.varnish-cache.org/docs/trunk/phk/http20.html 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.
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.
Historically, PHK was a very vocal criticizer of SPDY and HTTP/2: http://www.varnish-cache.org/docs/trunk/phk/http20.html 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.
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?
Faster and far more configurable, the configuration language (VCL) compiles to 'C' and you can inline bits of C if you want. https://www.varnish-cache.org/trac/wiki/ArchitectureInlineC
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?
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.
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 f…
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.
Historically, PHK was a very vocal criticizer of SPDY and HTTP/2: http://www.varnish-cache.org/docs/trunk/phk/http20.html 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.
The original brief for H2 was to have the same semantics etc, as HTTP/1.x 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.
Earlier quoted context omitted.
Faster and far more configurable, the configuration language (VCL) compiles to 'C' and you can inline bits of C if you want. https://www.varnish-cache.org/trac/wiki/ArchitectureInlineC
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.
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.
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…