Caching 3: debugging cache settings¶
To test and verify cache settings there are various methods. I’ll list them here including gotchas and handy tips.
The document describes firefox, as that is got the best tools for debugging your cache. Firebug and livehttpheaders are both firefox extensions.
Firebug’s net stats¶
When you run firebug and click the “net” tab, you’ll see the browser’s activity. It is often a surprisingly quick way to spot whether the whole shebang is downloaded or whether there’s a lot of caching.
Warning: the “net” tab also shows activity on javascript/css files, even when they’re coming from the local browser cache. So do not take firebug as proof that something is requested from the server. You can take the absence of items in firebug’s “net” tab as proof that they’re not downloaded, though.
Clicking on a downloaded item in firebug’s “net” tab gives you the request and response headers. Handy for a quick check.
Livehttpheaders¶
All praise livehttpheaders! This is your most important tool. It captures the headers of all outgoing requests and incoming responses.
There are two relevant tabs in the livehttpheaders window: the “headers” tab for full headers or “generator” for just a list of requested items. Use the second one if you only want to check which items are requested. Use the first for detailed inspection.
Some comments on reading what you’re seeing:
- Varnish doesn’t remove headers, it only appends. So something served by varnish from its cache will still have “served by zope” headers! Don’t let yourself be fooled by this.
- Varnish doesn’t give much info. If you put varnish in debug mode, the X-Varnish header will show one number when varnish stored this request. It will show two numbers (the “number” of the original request that was stored and the “number” of the current request) when there’s a cache hit (which means that varnish served the request from its cache).
- Look for the presence of an X-Caching-Rule-Id and/or the X-Header-Set-Id header. Those mean cachefu got its hands on the request, else not. Very handy for debugging your cachefu configuration, as it says which cachefu rule and which header set got used. (Note: X-Cache-Headers-Set-By is not always present, so that is not a reliable indicator).
Logfiles¶
When you doubt firebug or livehttpheaders or your own observations, nothing beats a look at the logfiles of zope and apache. Varnish has no real logfile (for performance reasons), but you can have it show apache-like logging of what’s currently being served: bin/varnishncsa; but this does not show everything – for example it swallows some of the purge requests.
The apache logfile tells you the truth about what your browser requests from the server. Firebug’s net stats, for instance, used to list items that weren’t really downloaded after all... Apache’s log will tell you the truth. (And livehttpheaders, too).
Zope’s access log tells you what wasn’t handled by the proxy cache. A request returned by varnish will include the original zope headers, so you cannot take that as proof that something was actually served by zope. You can trust the access log, though. A tail -f on the access log in a terminal window and some clicking in your browser at the same time can prove very instructional.
