Now that i've finally got some varnish hits on my site i've been doing a bit of testing on my site and am not sure I'm experiencing the full performance benefits of varnish.

My VCL is pretty much as per the example with the respective examples uncommented as needed.

Varnish stat reports an average hit rate of about 0.7 over time.

For anonymous users with the same permissions.

In Firefox i start a browsing session as an anonymous user.
What I am finding is that when i start a new browsing session to my site the initial visit to a page will be a varnish miss but if i refresh the page i will then get a varnish hit. (Status code 304 Not Modified which i believe to be normal behaviour)

I then start another anonymous browsing session using chrome and when i visit that same page i would expect that i should receive the page through varnish but instead the page is a varnish miss and it comes from apache. if i then refresh that page in the same chrome window however it gives me a varnish hit.

So i looked into how this is suppose to work at the top of the example ie.

* 2. Retrieve X-Authcache-Key form the backend and add it onto the request
* ------------------------------------------------------------------------
* The authcache key is a value which is unique for every combination of Drupal
* user roles. The keys of two users are only equal if both of them have the
* exact same combination of user roles and therefore identical permissions.
*
* Authcache Varnish exposes the callback /authcache-varnish-get-key which
* returns the authcache key for the currently logged in user. Except when one
* of the roles is excluded from caching, in that case no key is returned from
* the callback.

So I'm wondering should I be seeing the X-authcache-key in the browsers headers?

Is there anything i can check to see whats going on.

thanks in advance again for your help

Comments

znerol’s picture

znerol CreditAttribution: znerol commented

So I'm wondering should I be seeing the X-authcache-key in the browsers headers?

No, this is a request header, added by Varnish when forwarding a request to the backend.

Is there anything i can check to see whats going on.

Checkout varnishlog, if you want to analyze backend connections, try -b.

Colin @ PCMarket’s picture

Colin @ PCMarket CreditAttribution: Colin @ PCMarket commented

Thanks znerol

What am i looking for in particular in the varnishlog

Is what i described expected behaviour or an indication that something is misconfigured?

znerol’s picture

znerol CreditAttribution: znerol commented

If your cache is warm (i.e. it contains an entry for a particular page), then the first page request of a newly opened browser should result in a cache hit.

Colin @ PCMarket’s picture

Colin @ PCMarket CreditAttribution: Colin @ PCMarket commented

What would be the likely cause of a page with a cache entry not being served to a newly opened browser?

i have in my settings.php

// Expiration of cached pages.
$conf['page_cache_maximum_age'] = 21660;
// minimum cache lifetime.
$conf['cache_lifetime'] = 30;

not sure if this makes a difference.

znerol’s picture

znerol CreditAttribution: znerol commented

Do you get a cache-HIT when you test with something different than a browser? E.g. with isvarnishworking.com?

Colin @ PCMarket’s picture

Colin @ PCMarket CreditAttribution: Colin @ PCMarket commented

on isvarnishworking i only get a cache hit on refresh

znerol’s picture

znerol CreditAttribution: znerol commented

I do not understand that. iswarnishworking will start an entirely new request (no cookies, nothing) everytime you submit the page. Could you please post the output from your first and from the second attempt here?

Colin @ PCMarket’s picture

Colin @ PCMarket CreditAttribution: Colin @ PCMarket commented

Output from entering URL into isvarnishworking first time

Yes! Sort Of

The url we checked: http://www.pcmarket.net.au/blog/our-story
HTTP/1.1 200 OK
Server: Apache/2.2.29 (Unix) mod_ssl/2.2.29 OpenSSL/1.0.1e-fips mod_bwlimited/1.4
X-Powered-By: PHP/5.4.33
Etag: "1412950113-1"
Content-Language: en
X-Generator: Drupal 7 (http://drupal.org)
Link: ; rel="canonical",; rel="shortlink"
Cache-Control: public, max-age=21660
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Content-Encoding: gzip
Last-Modified: Fri, 10 Oct 2014 14:08:33 GMT
Content-Type: text/html; charset=utf-8
Date: Fri, 10 Oct 2014 14:08:35 GMT
X-Varnish: 989661809
Age: 0
Via: 1.1 varnish
Connection: keep-alive
Vary: Accept-Encoding,User-Agent, Cookie
X-Varnish-Cache: MISS

And then refresh results

YES

The url we checked: http://www.pcmarket.net.au/blog/our-story
HTTP/1.1 200 OK
Server: Apache/2.2.29 (Unix) mod_ssl/2.2.29 OpenSSL/1.0.1e-fips mod_bwlimited/1.4
X-Powered-By: PHP/5.4.33
Etag: "1412950113-1"
Content-Language: en
X-Generator: Drupal 7 (http://drupal.org)
Link: ; rel="canonical",; rel="shortlink"
Cache-Control: public, max-age=21660
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Content-Encoding: gzip
Last-Modified: Fri, 10 Oct 2014 14:08:33 GMT
Content-Type: text/html; charset=utf-8
Date: Fri, 10 Oct 2014 14:08:54 GMT
X-Varnish: 989661811 989661809
Age: 19
Via: 1.1 varnish
Connection: keep-alive
Vary: Accept-Encoding,User-Agent, Cookie
X-Varnish-Cache: HIT

znerol’s picture

znerol CreditAttribution: znerol commented

When do you clear caches? I.e., how often do you run cron?

znerol’s picture

znerol CreditAttribution: znerol commented

See also Authcache 2 tuning guide - optimize cache-hit ratio, especially the part about cron.

Colin @ PCMarket’s picture

Colin @ PCMarket CreditAttribution: Colin @ PCMarket commented

i don't clear caches very often

cron is currently set to run every 3 hours

znerol’s picture

znerol CreditAttribution: znerol commented
Status: Active » Fixed

According to #8 I believe that Authcache/Varnish is working as intended. For further tuning please consider the following things:

Double check your Varnish (the Drupal module) settings, especially whether or not the page cache is flushed during cron runs and also the cache clearing mode: Drupal Default means that the cache is cleared whenever a node is edited, or similar actions happen on the page. If edits happen frequently on your site, consider setting up the Cache Expiration module and switch to Selective mode.

You currently deliver pages with Cache-Control: public, max-age=21660 to the client. This means that browsers may cache the response for up to 6 days. For most sites this value is far too high.

Both of these points are generic Varnish configuration issues. If you need further support, then you will be better off asking over in the Varnish module issue queue or directly in the Varnish Forums.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.