Testing Varnish

Spotting a cached page

Varnish sets headers to give some clues.

Open Chrome Developer tools by hitting F12 navigate to the network tag and click on the page, filtering by Doc should make this easier to find.

The two headers are X-Varnish, which tells you if varnish is hit, and X-Cache which will give more details on if there has been a cache HIT or MISS.

Warning

Varnish can be setup to exclude these headers, if they are not on the page it does not mean varnish isn't in use.

Looking out for Cache leaks

A cache leak is where information which is meant to be dynamic for a page is cached and delivered where it should not be.

To test this you can often just hit a page multiple times under different circumstances, some common cache leaks on a magento store are:

User Account Info

Log into the user account area as one user and then hit it again as another with out clearing the cache. Each user should have the correct details, if the second user see the details of the first the means user information is being cached.

User Info on other Pages

Often over looked is account info on pages outside of the account page.

You can test this the same way by logging in as different users and looking out for any where your site has a personalised message i.e. 'Thanks for ordering [User]'

Blocks on template pages

Magento makes use of the same templates to generate multiple pages, some times these can include a block loaded by the template which needs to be different i.e. a category description.

This is more likely to happen with custom blocks, if you have extra functionality on category or product pages it is good to check.

The only real way to test this is to navigate the site once the cache is warm and pay attention to the content of each different part of the site, is the product description describing the correct product? are the related product relevant to this? etc.

Turpentine Varnish module for Magento

The docs can be found here. I have used snippets from these below.

Concepts

ESI_Cache_Policy

A Magento page is made up of blocks, the ESI_Cache_Policy define how each block should be stored.

Block Access

This is what user a block is cached for.

private        : one version per client is stored in cache (the session cookie identifies which client gets which cached version of the block)
public         : one version of a block is stored for the entire website (only one cached version of the block exist and it is served to every client)
customer_group : one version per customer group is stored in cache (special customer group cookie is used)

Scope

Some times you have blocks used on multiple pages, maybe the links in the footer. This is defined by the scope.

page   : one version of the block is cached per page (identified by the URL)
global : one version of the block is stored for the entire site

Monitoring

Running the varnishstat command will display dynamic data in the terminal of all available Varnish variables.

This can be filtered with the -f option and accepts wildcards *.

This is especially useful when trying to find out if Varnish's storage is filling up and nuking pages.

You can check this by running varnishstat -f MAIN.n* and looking for the n_lru_nuked variable. If this is changing at all it means that varnish is dropping old objects from the cache to make room for new ones.

So either you need to increase the cache size VARNISH_STORAGE, or alter your default.vcl file to stop caching unnecessary items.

It's worth noting that if you see the MAIN.n_lru_nuked variable listed in the varnishstat output this means that at some point Varnish has reached the memory limit. If Varnish has never hit the memory limit this variable will not appear in the output at all.

If we look at some other variables we can see the current size and free space of the cache.

varnishstat -f SMA*

If you run the above you should see the SMA.s0.g_bytes and SMA.s0.g_space variables.

SMA.s0.g_space is the free space available for Varnish to create new cache objects

SMA.s0.g_bytes is the allocated space that Varnish is currently using to store cache objects

If you add these together, you should get a value that roughly matches the limit that's been set in /etc/varnish/varnish.params.