Header

Varnish is a very popular software package that can dramatically accelerate the work of serving HTTP pages. Varnish caches fully-rendered responses to HTTP requests and serves them without the delay of building content from scratch. Because it’s so much more efficient than building a page with Apache and Drupal, Lullabot regularly deploys Varnish when a site needs to handle high levels of anonymous traffic. In many situations, installing Varnish on the same machine as MySQL and Apache can help squeeze more performance out of a single box. However in most of our deployments, we’re working with “high availability” setups, where dedicated servers handle different functions and redundant backup servers are on hand for every piece of the infrastructure. That means two database servers, two web servers, two Varnish servers, and so on.

A typical Drupal high-availability setup with Varnish.

This article is all about configuring Varnish optimally for these high-availability setups, in which multiple dedicated back-end servers are protected from heavy traffic by Varnish serving cached content to the outside world. We also have some neat tricks for server maintenance, optimizing your cached content, and configuring Varnish to act as a fail-safe even if all of your back-end servers go down.

Basic Varnish Configuration

Varnish usually has three locations of configuration. The boot script, the system-wide configuration, and the VCL file that does most of the work.

The first script that starts up Varnish is usually located with the rest of your system startup scripts at  /etc/init.d/varnish . This file rarely needs adjustments, but it can be interesting to read or help you locate further configuration (since the startup script is responsible for calling the next file).

The second file is usually located at  /etc/sysconfig/varnish  (on CentOS and RedHat machines) or  /etc/default/varnish  (on Ubuntu). This file defines global configuration for Varnish such as which port it should run on and where it should store its cache. Typically it contains 5 different ways of writing the same thing. It doesn’t matter which option you use: just be sure to change your storage backend. The default is usually “file”, which stores cached information on disk. Be absolutely sure to change this to “malloc”, which stores information in memory! If you don’t have enough memory in your box for a decent sized cache (say a few gigabytes), consider a memory upgrade.

Here’s a configuration that we have running on a very popular site with a large number of images and pages being cached (this is using the “Option 2″ in the /etc/sysconfig/varnish file):

Footer