What is Varnish?
If you know that you'll have a large group of website visitors that periodically (and simultaneously) visit your website for the same content, it doesn't make sense to size your server large enough to handle even the largest possible group of website visitors. Instead, you would make your site's content available to an application that can serve copies of content instead of having to re-create each content page dynamically for each website visitor. One application used for this purpose is Varnish.
Varnish is a reverse proxy HTTP accelerator that is often placed in front of Drupal websites to cache content, usually for anonymous website visitors. Because Varnish is a separate service, the type of the Drupal site's web server software (such as Apache, Nginx, Comanche, or Internet Information Services (IIS) ) doesn't matter — it just works.
Why is Varnish recommended so often for Drupal websites?
In a word – scalability. For each end user accessing the back end of your Drupal site, queries are made between the website and the database, active cache, spam filter, and update service. A web page is then built dynamically and delivered to the user. This system works fine for low-traffic sites, but if you’re looking to support the heavy traffic a large audience brings, your server alone will struggle under the weight. Varnish works to take the load off of your server.
Varnish is transparent to website visitors, handling content requests between website visitors and the web server backend. Any content presented for display by the server (surfaced) also includes the correct cache headers and is stored for a limited time. The are many advantages to using Varnish, including the following:
- Serving content from an in-memory cache means no slow PHP execution and no slow MySQL queries.
- Varnish delivers content at a much higher rate than stock Drupal can.
- The headers are respected entirely from Drupal, so unless something is specifically overridden in the Varnish configuration, Varnish will cache whatever content Drupal directs it to cache.
All of these together make websites behind Varnish fast! Even though the effects are felt only by anonymous users, the majority of traffic for most websites is likely anonymous so the benefit would be great.
Although Drupal has several potential caching strategies, it's arguably Varnish that provides the easiest one to set up when balanced against speed benefits:
- Drupal's built-in database cache system - A slow system compared to memory; locked to the database
- Boost module - Generally, an acceptable choice on memory poor servers, but caches pages as files in the filesystem (this can lead to problems on network filesystems like gluster due to the high rate of file read/write operations performed)
- Memcached - A great choice that works well with Varnish, although primarily used for lower-level cache (for example, caching bootstrap modules and views)
Memcached forms a cache backend that Drupal can interact with actively to set and get cached items where Varnish is a passive cache that Drupal does not know about.
- Redis and MongoDB - Similar to Memcache, they act as an active cache that the Drupal website can set and get items from
Drupal requires additional work to get either Redis or Mongo working, which makes this method more technical to implement.
Installing Varnish is a straightforward process on Debian, Red Hat, and OS X operating systems (but CentOS requires an additional repository). To install Varnish, run the following command:
(yum|apt-get|brew) install varnish
Be sure to change the default configuration options in
/etc/default/varnish both to listen on port 80 and to have a memory limit sufficient for your server.
For more information about installing Varnish, see Installing Varnish from source code on varnish-cache.org.
To configure how Varnish caches your website and how it can speed up website access for anonymous users, edit its Varnish configuration language (VCL) files to determine Varnish's behavior.
Acquia Cloud Enterprise accounts with dedicated load balancers are required to use a custom VCL. For more information on customizing Varnish on Acquia Cloud Enterprise, see Custom Varnish configuration for Acquia Cloud Enterprise sites.
For more information about configuring your Varnish cache for its best performance, see the FourKitchens VCL file, Acquia's simplified VCL file, and the Varnish documentation pages. The Drupal community also maintains documentation
Verifying that Varnish is working
One of the easiest ways to ensure that Varnish is working as expected is to visit the Is Varnish Working website and enter your website's URL. If Varnish is working for your site, it displays Yes! along with your site's headers.
You can also manually verify Varnish operations. Use the following command at a command prompt:
curl -IX http://domain.com
domain.com is your site's domain. This returns the headers for the document you request and generally looks like this:
HTTP/1.1 301 Moved PermanentlyServer: nginxContent-Type: text/html; charset=iso-8859-1Location: http://www.acquia.com/Cache-Control: max-age=1209600Expires: Fri, 27 Jun 2014 11:56:12 GMTVary: Accept-EncodingDate: Tue, 17 Jun 2014 20:54:38 GMTX-Varnish: 1250490910 1246657350Age: 377906Via: 1.1 varnishConnection: keep-aliveX-Cache: HITX-Cache-Hits: 10025
The important lines are
X-Cache: HIT, which says that it was not a cache
Age: 377906 because that confirms that the page has been stored in cache for that amount of time.
In Chrome, you can also use Developer Tools to see the HIT or MISS value.
- Open Developer Tools.
- Click the Network tab.
- Click the resource you want to view, which is usually (but not always) the HTML page.
- View the Headers tab.
- Look for both the "X-Cache" line to see if it was a HIT or a MISS and the "Age" line to see how old the document is.
What happens when I update my site’s content?
Varnish will, by default, hold cached pages in its memory for two minutes. After this period, the page will be discarded from the cache. The next time this content is requested, it will be created and delivered by the backend, and a new static copy will be stored in the Varnish cache. If necessary, you can manually invalidate cached objects by either purging them from the cache or banning them from being served from the cache. Varnish Software provides training material for these cache invalidation strategies, and you can find resources in pages linked to this one.