I love varnish announcements. Their messages seemingly have a 78% likelihood of being from the machines themselves.
And, frankly, I think the machines _are_ happy to make the announcement.
Varnish 4.0.2 released
21–30 of 56 posts
Re: Varnish 4.0.2 released
#22My 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.
Re: Varnish 4.0.2 released
#23We've been long vacillating on using Varnish to power our E-commerce store but from what we've read, Varnish is not a good solution in cases where cookies are part of most of web traffic. Is this true?
I just throw away the default config and write a vcl to do what I want.
You can cache while using cookies. If you use a cookie to change the page in any way add Cookie to you Vary headers. In Varnish I don't cache response with Vary ~ "Cookie". I also don't cache any response that sets a cookie.
Now if you have a backend that does modify the page using what is in a cookie but doesn't set the Vary header, then using Varnish can be quite a pain. This is hardly Varnish's fault that the backend is crappy.
Re: Varnish 4.0.2 released
#24We've been long vacillating on using Varnish to power our E-commerce store but from what we've read, Varnish is not a good solution in cases where cookies are part of most of web traffic. Is this true?
In addition to other answers - it depends what the cookies are for -- if your users only get a session cookie after logging in (before that they only have front-end cookies for things like google analytics / remembering which widget on the site is currently active / etc) then you can ignore front-end cookies, thus successfully caching for all not-logged-in users:
if(req.http.Cookie) {
# ignore front-end cookies (prefixed with "ui-")
set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(ui-[a-z-]+)=[^;]*", "");
# ignore google cookies
set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(__[a-z]+|has_js)=[^;]*", "");
# Remove a ";" prefix, if present.
set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", "");
# Remove empty cookies.
if (req.http.Cookie ~ "^\s*$") {
unset req.http.Cookie;
}
}
Re: Varnish 4.0.2 released
#25Does anyone have a fairly basic varnish config that deals with a) non-www to www redirects, b) works with https certificates (with the Cloudfare config) , , c) allows CORS for fonts on cloudfront and d) switches off caching for all /admin pages? Varnish has proven to be very hard to use with nginx in the above setup. Especially, trying to understand the ssl bit is getting to be really hard. Can it also work with spdy…
Not generating the www redirect (IMO that's more of a web server / application layer job than a cache job); but you can make varnish cache www and non-www objects together:
if (req.http.host == "www.foo.net") {
set req.http.host = "foo.net";
}Re: Varnish 4.0.2 released
#26Does anyone have a fairly basic varnish config that deals with a) non-www to www redirects, b) works with https certificates (with the Cloudfare config) , , c) allows CORS for fonts on cloudfront and d) switches off caching for all /admin pages? Varnish has proven to be very hard to use with nginx in the above setup. Especially, trying to understand the ssl bit is getting to be really hard. Can it also work with spdy…
Not generating the www redirect (IMO that's more of a web server / application layer job than a cache job); but you can make varnish cache www and non-www objects together: if (req.http.host == "www.foo.net") { set req.http.host = "foo.net"; }
Is this ever a good idea? Doesn't making www.foo.net and foo.net separate but identical cause an indexing split (and index ranking split) at search engines? Why would you ever want that split for the same pages at two different domains, unless they're serving different content?
Re: Varnish 4.0.2 released
#27I had to click three links to discover what Varnish is. So either I'm dumb or blind either there is no single description of what the product does on the home page copy.
Re: Varnish 4.0.2 released
#28Earlier quoted context omitted.
Not generating the www redirect (IMO that's more of a web server / application layer job than a cache job); but you can make varnish cache www and non-www objects together: if (req.http.host == "www.foo.net") { set req.http.host = "foo.net"; }
Is this ever a good idea? Doesn't making www.foo.net and foo.net separate but identical cause an indexing split (and index ranking split) at search engines? Why would you ever want that split for the same pages at two different domains, unless they're serving different content?
Now that you mention it, I forget why that specific snippet is in my config... it is part of a block of similar-but-more-useful things (specifically, having multiple caches serving the same static content from a variety of different domain names)
Re: Varnish 4.0.2 released
#29I had to click three links to discover what Varnish is. So either I'm dumb or blind either there is no single description of what the product does on the home page copy.
It's probably assumed to some degree that you know what it is at this point. It's the industry standard HTTP full-page cache daemon.
Re: Varnish 4.0.2 released
#30Varnish and caching in general can be a complete mind-freak the first few times you experience it, however after working with it nearly daily for the last 3 years, I've come to love it. It has allowed me to scale a number of WordPress websites far beyond where they had business being (34mm UV/180mm PV per month on a handful of servers). Super excited to see them continuing to build in great features.