Hi,
When checking on http://www.isvarnishworking.com one of Drupal 7 websites, I always see:
The url we checked: thewebsite.tld
HTTP/1.1 200 OK
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/5.3.3
X-Drupal-Cache: MISS
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
ETag: "1379724987"
Content-Language: en
X-Generator: Drupal 7 (http://drupal.org)
Link: <http://thewebsite.tld/>; rel="shortlink",<http://thewebsite.tld/>; rel="canonical"
Last-Modified: Sat, 21 Sep 2013 00:56:27 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 146598
Accept-Ranges: bytes
Date: Sat, 21 Sep 2013 00:56:29 GMT
X-Varnish: 1749894895
Age: 0
Via: 1.1 varnish
Connection: keep-aliveVarnish is running on the server, the Varnish module has been enabled, secret code provided and configuration page shows green for Varnish 3.x version. The settings.php file initially contained only the following lines recommended by the module's readme file:
// Add Varnish as the page cache handler.
$conf['cache_backends'] = array('sites/all/modules/varnish/varnish.cache.inc');
$conf['cache_class_cache_page'] = 'VarnishCache';
// Drupal 7 does not cache pages when we invoke hooks during bootstrap.
// This needs to be disabled.
$conf['page_cache_invoke_hooks'] = FALSE;However, trying to get it working I also added:
$conf['cache'] = 1;
$conf['cache_lifetime'] = 0;
$conf['page_cache_maximum_age'] = 21600;
$conf['reverse_proxy_header'] = 'HTTP_X_FORWARDED_FOR';
$conf['omit_vary_cookie'] = TRUE;
$conf['reverse_proxy'] = TRUE;
$conf['reverse_proxy_addresses'] = array('xxx.xxx.xxx.xxx');
#$conf['reverse_proxy_header'] = 'HTTP_X_CLUSTER_CLIENT_IP';Unfortunately, nothing seems to be making this work and http://www.isvarnishworking.com keeps showing
X-Drupal-Cache: MISS
I have disabled all the modules listed on http://akyl.net/modules-break-varnish-caching-and-how-fix-them, which seem to break Varnish caching. What else, what kind of other modules might be interfering to this situation, anyone can elaborate?
Comments
Cache Lifetime
Try changing cache life time to:
$conf['cache_lifetime'] = 300;See if that makes a difference.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
Header says not to cache.
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0Drupal anonymous page caching is either turned off or a site module is disabling caching.
X-Varnish: 1749894895This request was not served from Varnish cache. If it was, both the ID of the current request and the ID of the request that populated the cache would be shown. See https://www.varnish-cache.org/docs/2.1/faq/http.html for details.
If you want to hard code the configuration, here's what I'm looking for in https://drupal.org/project/site_audit :
// Enable anonymous page caching.$conf['cache'] = 1;
// Expiration of cached pages.
$conf['page_cache_maximum_age'] = 900;
// No minimum cache lifetime.
$conf['cache_lifetime'] = 0;
Now, just to make things a little more confusing, Varnish can cache a Drupal cache miss and serve a Varnish cache hit from a Drupal cache miss. That's not what's happening in this case, however.
Check the code ...
If you look in bootstrap.inc::_drupal_bootstrap_page_cache()
You will see:
if (!isset($_COOKIE[session_name()]) && $cache_enabled) {...
$cache = drupal_page_get_cache();
if (is_object($cache)) {
...
}
}
So, one of these conditions is not met.
The first one checks if a cookie is set, there isn't one in the headers you posted.
The second one on the same line checks if cache is enabled. You do have $conf['cache] = 1, so it should be enabled. However, some modules are known to disable cache in certain cases.
Check this article: Beware of Drupal modules that disable the page cache, to see if any of your modules do that.
The third condition (the second if) tries to retrieve the item from the cache, and is not able to do so. Don't have time now to see what VarnishCache does in this case, but try to comment out the two lines like so:
//$conf['cache_backends'] = array('sites/all/modules/varnish/varnish.cache.inc');//$conf['cache_class_cache_page'] = 'VarnishCache';
Then try. Drupal's regular page cache (using the database) will kick in, and send the correct headers to Varnish to cache the page.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
vcl config file edited?
Hi,
Try this in your vcl config file, maybe it will help.
# Respond to incoming requests.
sub vcl_recv {
# Remove all cookies that Drupal doesn't need to know about. ANY remaining
# cookie will cause the request to pass-through to Apache. For the most part
# we always set the NO_CACHE cookie after any POST request, disabling the
# Varnish cache temporarily. The session cookie allows all authenticated users
# to pass through as long as they're logged in.
if (req.http.Cookie) {
set req.http.Cookie = ";" + req.http.Cookie;
set req.http.Cookie = regsuball(req.http.Cookie, "; +", ";");
set req.http.Cookie = regsuball(req.http.Cookie, ";(SESS[a-z0-9]+|NO_CACHE)=", "; \1=");
set req.http.Cookie = regsuball(req.http.Cookie, ";[^ ][^;]*", "");
set req.http.Cookie = regsuball(req.http.Cookie, "^[; ]+|[; ]+$", "");
if (req.http.Cookie == "") {
# If there are no remaining cookies, remove the cookie header. If there
# aren't any cookie headers, Varnish's default behavior will be to cache
# the page.
unset req.http.Cookie;
}
else {
# If there are any cookies left (a session or NO_CACHE cookie), do not
# cache the page. Pass it on to Apache directly.
return (pass);
}
}
}
I am seeing a similar issue.
I am seeing a similar issue. All caching configuration are turned on properly but something and somewhere is invalidating the cache and I keep getting a cache miss. I am trying to debug and figure out what is causing this. I asked a question at http://drupal.stackexchange.com/ maybe someone can give some pointers.
I have a project called
I have a project called varnish_debug, which allows to investigate that easily.
There are 4 ways for failed Cache hits:
For this last one, you can use the varnish_debug sandbox and it will show you the SESSION and Cookie vars in the JS console. (Drupal.settings.varnish_debug)
https://drupal.org/sandbox/Fabianx/1259074
Hope that helps!
Thanks. But I suspect some
Thanks. But I suspect some poor coding in modules and theme layers. I see a lot of drupal_add_js in hook_init. I have heard that this usually, if not done properly, could result in invalidating the page cache.
May be you are using google pagespeed
I have this promble befor,I turn off google pagespeed and anything turn good.
直接把google pagespeed 关闭就好了
Because of Varnish module code
kbahey's latest reply is correct. Look this code in varnish.cache.inc:
<?php
class VarnishCache implements DrupalCacheInterface {
protected $bin;
function __construct($bin) {
$this->bin = $bin;
}
function get($cid) {
return FALSE;
}
......
}
?>
the get() function always returns FALSE and according to the code in bootstrap.inc:
<?php$cache = drupal_page_get_cache();
// If there is a cached page, display it.
if (is_object($cache)) {
header('X-Drupal-Cache: HIT');
// Restore the metadata cached with the page.
$_GET['q'] = $cache->data['path'];
drupal_set_title($cache->data['title'], PASS_THROUGH);
date_default_timezone_set(drupal_get_user_timezone());
// If the skipping of the bootstrap hooks is not enforced, call
// hook_boot.
if (variable_get('page_cache_invoke_hooks', TRUE)) {
bootstrap_invoke_all('boot');
}
drupal_serve_page_from_cache($cache);
// If the skipping of the bootstrap hooks is not enforced, call
// hook_exit.
if (variable_get('page_cache_invoke_hooks', TRUE)) {
bootstrap_invoke_all('exit');
}
// We are done.
exit;
}
else {
header('X-Drupal-Cache: MISS');
}
?>
Because get() returns FALSE, drupal_page_get_cache() will return an invalid cache object and the condition in else will be executed, which results in setting of X-Drupal-Cache: MISS header. So, if you comment out the configuration about Varnish module in settings as kbahey has pointed out then you'll see X-Drupal-Cache: HIT.
Simple Solution
Solution is rather simple "yngens"
Line Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
Tells you that your cache control is not set and varnish is not caching because of that. So what to do? Go simply to performance admin page and set cacheing of pages for anonymous users and set some min and max time for that, after some refreshes, above line will change and you will have "Yes" answer on isvarnishworking page. I talked more about that here http://drupaldump.com/boost-and-varnish-and-general-tips-and-rants-about... also there were some nice suggestions going on in this topic for other use cases.
Drupal Specialist at http://adriadrop.com/
And if that doesn't help,
And if that doesn't help, then you probably have some cookies in the end. Try this configuration that will remove all cookies. If you get HITs all the way then you will know what is the problem http://drupaldump.com/varnish-simple-troubleshooting-defaultvcl
Drupal Specialist at http://adriadrop.com/
Some information
There are few things to sum-up regarding the page-cache ,
two ways,
- Drupal-cache
- Varnish cache
Now according to the configuration over settings.php for varnish Drupal-cache is ignored
so expected result should be Drupal-cache even Miss but Varnish cache shows HIT
But if I request page directly over apache then expected result should be
Drupal-cache even HIT respective that page caching for anonymous user is on.
Now confusion for the use of
<?php$conf['page_cache_invoke_hooks'];
?>
if that variable false then any hooks will be executed during bootstrap(generally we use hook_boot) but what my findings is that if we use hook_boot(which executes with each request) any page will not be cached any more for anonymous user even according to varnish API
<?php$conf['page_cache_invoke_hooks'] = FALSE;
?>
Varnish hits + works, but drupal miss?
Hello,
In my scenario, I've got varnish installed and working well. Varnishstat gives very high hitrate avg (as high as 1.0000 under a loadimpact test with 50 concurrent users, paired with very healthy server load at 0.05). But Drupal always reports MISS.
Should I care about the MISS on the drupal side?
Varnish is doing it's thing. and doing it well.. I've got the drupal cache expiration and varnish modules in place set to external expiry. isvarnishworking reports yes.
Nothing I do seems to get the drupal cache to hit (tried on multiple sites) - but perhaps this is due to modules, or theming layer etc. Just not sure if I should spend more time trying to resolve this, or simply be happy I have varnish working solidly.
Please advise!
Kind regards,
Adon
that makes sense
If your varnish cache is set to very long expiry, a MISS for drupal cache in your response headers makes sense.
Imagine this, you send a request for node/58743. Varnish looks in its cache, but it's not there. So it passes the request to drupal. Drupal looks in its cache, it's also not there, so it generates the page and sends the response to Varnish. Varnish serves the response to the orginator and stores a copy in its cache. The headers will indicate a varnish miss and a drupal miss.
Now you request node/59743 again. Varnish looks in its cache, bingo it's a hit! So it serves the cached copy (with drupal MISS header), and adds a varnish HIT header. And that's what you'll get from now on for that request.
I imagine you could avoid
I imagine you could avoid this by just disabling the Drupal page cache if you're already using Varnish. I'd imagine that'd help avoid surprising behavior in other ways as well.
The Boise Drupal Guy!
Update on success
Thanks for the input!
My experience suggested that, as Garrett proposed, disabling the drupal cache and letting varnish do its thing gives me a better performance overall.
[I still have the drupal varnish + cache expiration modules enabled for now - but my guess is they are irrelevant if the drupal caching is not enabled. THESE MODULES ARE IMPORTANT ON THE VARNISH SIDE OF THE CACHE.. thanks for the correction, Dalin]
I still have the drupal
Not true. That's what is purging the Varnish cache when new content is created on your site. Otherwise all pages will just stay cached in Varnish until their max-age is reached.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
Make sense...
Good to know.. that actually makes sense (i was thinking in terms of drupal cache, but not in terms of varnish cache). Likely also explains why i encountered a few odd issues when varnish was running, but varnish+cache expire modules were not yet installed on a few of the other drupal sites on my system.
Much appreciated!!
Drupal MISS but Varnish HIT, serving auth users cached anon page
We're seeing kind of the opposite, and I'm hoping somebody would have a sense of where to look: we're seeing Drupal authenticated users sometimes visit /node pages and get the Varnish cached version instead, so in Chrome:
. Via:1.1 varnish
. X-Drupal-Cache:MISS
. X-Generator:Drupal 7 (http://drupal.org)
. X-Varnish:1702342629 1702299657
. X-Varnish-Cache:HIT
In this case, Drupal is correct, and Varnish is wrong. But only sometimes. And then occasionally on a page refresh Varnish will serve the non-Cached page again. Cookies in the Varnish log are identical. Not sure what to poke at to troubleshoot this!
Sounds like there's some
Sounds like there's some strange stuff in the cookie section of vcl_recv() in your default.vcl. Compare with the seminal example here:
https://www.lullabot.com/blog/article/configuring-varnish-high-availabil...
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
cookie weirdness
Agreed it's some kind of cookie madness, but the config was set up using that Lullabot example, verbatim, and worked great until the latest round of Drupal updates, or Chrome updates, or solar flares...
eta: I say Chrome because that's what I've been able to replicate this in, but I'll give the other browsers a shot to see if that narrows it down. It doesn't happen all the time in Chrome, either, so... sigh :/
Ok, well, if anybody else
Ok, well, if anybody else encounters this: it was an Optimizely cookie, it was larger than the max cookie size.
This can happen if you
This can happen if you use
$conf["cache_class_cache_page"] = "VarnishCache";This uses drupal cache_page cache bin in Varnish so drupal cache hit header never gets set.
$conf['cache_class_external_varnish_page'] = 'VarnishCache';Use this with the expire module to configure your cache and you should see x-drupal-cache: hit along with x-varnish-cache: hit (if configured in vcl) if your site actually gets to cache in the drupal cache bin as well as in varnish.
Not sure if it will help
Not sure if it will help anyone, but I had an errant session cookie stuck in my browser that was blocking caching. Restarting the browser and re-loading the site changed it to X-CACHE HIT (even after logging in and out of Drupal a few times).
CHROME!!!!!
It seems that what @emmonsaz said is right on. Even if you are using a private browsing session to test, Chrome might still will hold onto cookies. Before you go insane, first check via curl (curl -I http://example.com/), then check on a clean browser (one which has never hit the site before or you completely wipe browsing history). IF both appear to have the correct headers, restart the browser that is getting correct header and see if it fixed it.
Varnish Indicator Chrome Extension
Varnish Indicator Chrome Extension is the easiest way to check for Varnish hits and misses. The indicator is in your extension toolbar.
It says MISS on the comment edit page. In Chrome inspector headers:
Cache-Control:no-cache¿ are you netsperienced ?
♥ follow me @decibelplaces ∞