Speeding Up Apache And Drupal With Varnish

Varnish is a web application accelerator that provides an easy speed increase to most web applications and Drupal is no exception. It works by creating a reverse proxy service that sits in front of your web server and caches traffic that comes through it. When the page is requested, Varnish forwards the request to the web server to complete the request, the response that comes back from the web server is then cached by Varnish. This means that the next request to the same page is served by Varnish and not the web server, which results in a large speed increase.

The upshot of using Varnish with an application like Drupal is that when a request is made there is no hit to the web server (and thus PHP) and no hit to the database. Varnish works best with Drupal with anonymous traffic, as authenticated traffic requires cookies and custom HTML. Even so, you can see massive speed increases for any anonymous traffic on the site.

Varnish can be configured to run as a stand alone machine in front of a bunch of Apache nodes or as a front end to a single Apache server.

There are a few steps to getting Varnish up and running with Drupal on Apache, which starts with installing Apache.

Install And Configure Apache

To install Apache on Ubuntu use the following apt-get command.

sudo apt-get install apache2 apache2-mpm-prefork apache2-utils

Once installed you need to change the port that Apache listens to. This is because Varnish will be configured to listen on port 80 and act as a proxy to an internal port that you designate. The usual approach here is to use port 8080 as this is normal alternative HTTP port and so won't clash with anything else.

To change the port that Apache listens to just open up the file /etc/apache2/ports.conf and change the 'Listen' directive to 8080.

Listen 8080

It's probably a good idea to prevent access to port 8080 from the outside world. Although this isn't a large security breach it is bad practice to allow your users to bypass your Varnish server. This can be done via an Apache configuration option or via firewall rules.

Once done just restart Apache for the change to be picked up. This command will do this on most Linux boxes.

sudo service apache2 restart

With Apache up and running it is now time to install and configure Varnish.

Install And Configure Varnish

To install Varnish on Ubuntu just run the following apt-get command.

sudo apt-get install varnish

Once installed you will find the following three files that are important to the running of Varnish.

• /etc/default/varnish - This is a shell script fragment that is used by /etc/init.d/varnish to run Varnish with various options.
• /etc/varnish/default.vcl - This is a file that is used to control how Varnish acts with different requests. This is for things like how Varnish treats cookies and what paths should be excluded from being cached. The location of this file is set in the /etc/default/varnish file.
• /etc/varnish/secret - This is a file that is used as a way of securely allowing administrative access to the Varnish cache. Again, the location of this file is set in the /etc/default/varnish file.

The /etc/varnish/default file just needs to create the variables DAEMON_OPTS, NFILES and MEMLOCK, which are picked up by the /etc/init.d/varnish script. The /etc/varnish/default file is essentially a wrapper around running Varnish on the command line using the varnishd command.

The DAEOMON_OPTS variable controls the various aspects of how Varnish works including what port Varnish should listen on and so is the most important part of this file to understand. Any options added to this variable are passed directly to the varnishd service. The following options can be included in the DAEMON_OPTS variable to control how Varnish runs.

• -a - The port that Varnish should listen to for incoming traffic.
• -T - The location and port of the administration interface.
• -f - The location of the Varnish configuration file, normally stored at /etc/varnish/default.vcl.
• -S - The location of the Varnish secret file, normally stored at /etc/varnish/secret.
• -s - This sets the options for the location and size of the Varnish cache.
• -w - Configure the minimum, maximum and timeout length of the thread pool.
• -p - Set one of a number tuneable parameters. This can be used multiple times to set multiple parameters.

For more information on the available command line parameters see the official documentation on the varnishd command.

The following is a simple example of the /etc/default/varnish file that sets up some default values. This is normally used as a basic setup of Varnish on a machine that has limited resources.

# Should we start varnishd at boot?  Set to "no" to disable.
START=yes

# Maximum number of open files (for ulimit -n)
NFILES=131072

# Maximum locked memory size (for ulimit -l)
# Used for locking the shared memory log in memory.  If you increase log size,
# you need to increase this number as well
MEMLOCK=82000

# Default varnish instance name is the local nodename.  Can be overridden with
# the -n switch, to have more instances on a single server.
INSTANCE=$(uname -n)

DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,256m"

This sets up Varnish to have the following options:

• Line 2 - Sets the START variable to 'yes' to make Varnish start when the server reboots.
• Line 5 - Sets the NFILES variable to be 131072. This controls how many files Varnish can have open at once. The command ulimit -n ${NFILES:-131072} is run in the init.d file when Varnish is started.
• Line 10 - Sets the MEMLOCK variable to be 82000. This controls how the users soft limit for the maximum size that may be locked into memory. The command ulimit -l ${MEMLOCK:-82000} is ran in the init.d file when Varnish is started.
• Line 14 - Sets the INSTANCE variable to be the output of 'uname -n'. This is used when Varnish is configured to be part of a node cluster, which we won't be using in this case.
• Line 16 - Sets the DAEMON_OPTS variable to have the following options:
  • Set the port number to 80 from anywhere with the -a flag.
  • Set the administration port to be 6082 on the local machine with the -T flag.
  • Set the Varnish configuration file to be /etc/varnish/default.vcl with the -f flag.
  • Set the secret file location to be /etc/varnish/secret with the -S flag.
  • Set Varnish to store the cache in memory and make that memory 256m with the -s flag.

The following is a different setup of Varnish that tweaks some of the other available parameters. This setup is designed for a host with more resources.

# Should we start varnishd at boot?  Set to "no" to disable.
START=yes

# Maximum number of open files (for ulimit -n)
NFILES=131072

# Maximum locked memory size (for ulimit -l)
# Used for locking the shared memory log in memory.  If you increase log size,
# you need to increase this number as well
MEMLOCK=82000

# Default varnish instance name is the local nodename.  Can be overridden with
# the -n switch, to have more instances on a single server.
INSTANCE=$(uname -n)

# The minimum number of worker threads to start
VARNISH_MIN_THREADS=400

# The Maximum number of worker threads to start
VARNISH_MAX_THREADS=4000

# Idle timeout for worker threads
VARNISH_THREAD_TIMEOUT=120

DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -w ${VARNISH_MIN_THREADS},${VARNISH_MAX_THREADS},${VARNISH_THREAD_TIMEOUT} \
             -p thread_pool_add_delay=2 \
             -p thread_pools=2 \
             -p session_linger=50 \
             -p sess_workspace=262144 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc, 1024m"

Going line by line the following options are being set.

• Line 2 - Sets the START variable to 'yes' to make Varnish start when the server reboots.
• Line 5 - Sets the NFILES variable to be 131072. This controls how many files Varnish can have open at once. The command ulimit -n ${NFILES:-131072} is run in the init.d file when Varnish is started.
• Line 10 - Sets the MEMLOCK variable to be 82000. This controls how the users soft limit for the maximum size that may be locked into memory. The command ulimit -l ${MEMLOCK:-82000} is ran in the init.d file when Varnish is started.
• Line 14 - Sets the INSTANCE variable to be the output of 'uname -n'. This is used when Varnish is configured to be part of a node cluster, which we won't be using in this case.
• Line 17 - Sets a variable called VARNISH_MIN_THREADS that stores the minimum number of worker threads that Varnish will start.
• Line 20 - Sets a variable called VARNISH_MAX_THREADS that stores the maximum number of worker threads that Varnish will start.
• Line 23 - Sets a variable called VARNISH_THREAD_TIMEOUT that stores the idle timeout for worker threads.
• Line 25 - Sets the DAEMON_OPTS variable to have the following options:
  • Set the port number to 80 from anywhere with the -a flag.
  • Set the administration port to be 6082 on the local machine with the -T flag.
  • Configures the maximum and minimum number of worker threads that Varnish will start with the -w flag.
  • Sets a number of extra options using the -p flag. This includes setting the number of thread pools to 2 and slightly decreasing the amount of time that should elapse before a session is revoked.
  • Set the Varnish configuration file to be /etc/varnish/default.vcl with the -f flag.
  • Set the secret file location to be /etc/varnish/secret with the -S flag.
  • Set Varnish to store the cache in memory and make that memory 256m with the -s flag.

Next, we need to edit the default.vcl file to tell Varnish how to treat both incoming and outgoing requests. The default.vcl file uses a language called Varnish Configuration Language which Varnish converts into binary code that is executed when requests arrive. This is perhaps the most complex part of a Varnish setup, especially when taking Drupal into consideration as we need to do things like exclude certain pages and inspect cookies. This file contains a number of setup groups and sub routines. Any sub routines that you define here will override the default implementations that Varnish has for them.

The first thing we configure in this file is the backend integration. When we setup Apache in the previous step we made Apache listen on port 8080 for incoming requests so it is this port that we tell Varnish to use when asking for page caches. The following will configure and initialise a default backend listener on the local machine.

backend default {
  .host = "127.0.0.1";
  .port = "8080";
}

One thing that you should be careful of with Drupal is long page load times, especially when rebuilding the cache or doing other complex things. For this reason it is best to include some additional parameters to increase the time that Varnish will wait for a response from the web server. Without these timeout parameters in place you might see random Varnish errors appearing when Drupal takes too long to respond. Here is the modified default backend listener.

backend default {
  .host = "127.0.0.1";
  .port = "8080";
  .connect_timeout = 2s;
  .first_byte_timeout = 30s;
  .between_bytes_timeout = 10s;
}

The vcl_recv sub routine contains the main bulk of the Varnish configuration logic. This is the first subroutine to be fired when Varnish is sent a request. This controls how Varnish deals with cookies and which URL's should be included or excluded from the cache mechanisms. This is quite a long sub routine, but it is well documented, and essentially defines the following actions.

• What to do in the event of a backend failure.
• Set up forwarding of the IP address of the user to the server in a proxy header.
• What URLs to skip when storing cache objects.
• Optionally prevent access to certain restricted pages.
• Set up compression handling for the request.
• Don't cache downloadable files like PDF or Word Documents.
• Remove cookies that Drupal doesn't need to know about.

sub vcl_recv {
  # Use anonymous, cached pages if all backends are down.
  if (!req.backend.healthy) {
    unset req.http.Cookie;
  }
 
  # Allow the backend to serve up stale content if it is responding slowly.
  set req.grace = 6h;
 
  # Pipe these paths directly to Apache for streaming.
  if (req.url ~ "^/admin/content/backup_migrate/export") {
    return (pipe);
  }
 
  # Set up the X-Forwarded-for header with the client IP address.
  if (req.restarts == 0) {
    if (req.http.x-forwarded-for) {
      set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip;
    }
    else {
      set req.http.X-Forwarded-For = client.ip;
    }
  }
 
  # Do not cache these paths.
  if (req.url ~ "^/status\.php$" ||
      req.url ~ "^/update\.php" ||
      req.url ~ "^/install\.php" ||
      req.url ~ "^/batch/.*$" ||
      req.url ~ "^/admin" ||
      req.url ~ "^/admin/.*$" ||
      req.url ~ "^/user" ||
      req.url ~ "^/user/.*$" ||
      req.url ~ "^/users/.*$" ||
      req.url ~ "^/info/.*$" ||
      req.url ~ "^/flag/.*$" ||
      req.url ~ "^.*/ajax/.*$" ||
      req.url ~ "^.*/ahah/.*$") {
       return (pass);
  }

  # Do not allow outside access to cron.php or install.php.
  #if (req.url ~ "^/(cron|install)\.php$" && !client.ip ~ internal) {
    # Have Varnish throw the error directly.
  #  error 404 "Page not found.";
    # Use a custom error page that you've defined in Drupal at the path "404".
    # set req.url = "/404";
  #}

   # Handle compression correctly. Different browsers send different
   # "Accept-Encoding" headers, even though they mostly all support the same
   # compression mechanisms. By consolidating these compression headers into
   # a consistent format, we can reduce the size of the cache and get more hits.=
   # @see: http:// varnish.projects.linpro.no/wiki/FAQ/Compression
   if (req.http.Accept-Encoding) {
     if (req.http.Accept-Encoding ~ "gzip") {
       # If the browser supports it, we'll use gzip.
       set req.http.Accept-Encoding = "gzip";
     }
     else if (req.http.Accept-Encoding ~ "deflate") {
       # Next, try deflate if it is supported.
       set req.http.Accept-Encoding = "deflate";
     }
     else {
       # Unknown algorithm. Remove it and send unencoded.
       unset req.http.Accept-Encoding;
     }
   }

  # Always cache the following file types for all users. This list of extensions
  # appears twice, once here and again in vcl_fetch so make sure you edit both
  # and keep them equal.
  if (req.url ~ "(?i)\.(pdf|asc|dat|txt|doc|xls|ppt|tgz|csv|png|gif|jpeg|jpg|ico|swf|css|js)(\?.*)?$") {
    unset req.http.Cookie;
  }
 
  # Remove all cookies that Drupal doesn't need to know about. We explicitly 
  # list the ones that Drupal does need, the SESS and NO_CACHE. If, after 
  # running this code we find that either of these two cookies remains, we 
  # will pass as the page cannot be cached.
  if (req.http.Cookie) {
    # 1. Append a semi-colon to the front of the cookie string.
    # 2. Remove all spaces that appear after semi-colons.
    # 3. Match the cookies we want to keep, adding the space we removed 
    #    previously back. (\1) is first matching group in the regsuball.
    # 4. Remove all other cookies, identifying them by the fact that they have
    #    no space after the preceding semi-colon.
    # 5. Remove all spaces and semi-colons from the beginning and end of the 
    #    cookie string. 
    set req.http.Cookie = ";" + req.http.Cookie;
    set req.http.Cookie = regsuball(req.http.Cookie, "; +", ";");    
    set req.http.Cookie = regsuball(req.http.Cookie, ";(SESS[a-z0-9]+|SSESS[a-z0-9]+|NO_CACHE)=", "; \1=");
    set req.http.Cookie = regsuball(req.http.Cookie, ";[^ ][^;]*", "");
    set req.http.Cookie = regsuball(req.http.Cookie, "^[; ]+|[; ]+$", "");
 
    if (req.http.Cookie == "") {
      # If there are no remaining cookies, remove the cookie header. If there
      # aren't any cookie headers, Varnish's default behavior will be to cache
      # the page.
      unset req.http.Cookie;
    }
    else {
      # If there is any cookies left (a session or NO_CACHE cookie), do not
      # cache the page. Pass it on to Apache directly.
      return (pass);
    }
  }
}

The vcl_deliver sub routine is used to tweak the response to the client before being issued by Varnish. The most common use for this sub routine is to control what HTTP headers will be present in the response. The following is a typical example of the vcl_deliver sub routine.

sub vcl_deliver {
  # Remove some security specific common headers.
  remove resp.http.Via;
  remove resp.http.X-Whatever;
  remove resp.http.X-Powered-By;
  remove resp.http.X-Generator;
  remove resp.http.X-Varnish;
  remove resp.http.X-Drupal-Cache;
  remove resp.http.Server;

  if (obj.hits > 0) {
    set resp.http.X-Varnish-Cache = "HIT";
  }
  else {
    set resp.http.X-Varnish-Cache = "MISS";
  }
}

The first part of this removes some of the typical HTTP headers that reveal quite a bit about the server and architecture. This is generally considered a bad thing (mainly as it makes targeted attacks much easier) and so they should be removed. These are headers like Server, which shows what web server is being used (usually generated by Apache) and X-Generator, which is generated by Drupal.

The second part of this sub routine involves setting a 'HIT' or a 'MISS' to show if Varnish returned a cached page or not. This is useful in making sure things are working correctly or diagnosing any problems with the Varnish cache control.

The vcl_fetch sub routine controls how Varnish treats documents that have successfully been retrieved from the backend. The beresp variable is available here and can be used to tweak the cache settings before the retrieved document is returned.

The bottom of the sub routine adds support for ban lurker. This is a Varnish process that runs through the cache and bans various cache objects. A ban is a quick way of invalidating the cache without having to remove the object from the cache itself. When the object is next fetched from the cache it is evaluated to see if it has been banned. If it has then the new version of the page is requested, stored, and served.

sub vcl_fetch {
  # We need this to cache 404s, 301s, 500s. Otherwise, depending on backend but 
  # definitely in Drupal's case these responses are not cacheable by default.
  if (beresp.status == 404 || beresp.status == 301 || beresp.status == 500) {
    set beresp.ttl = 10m;
  }
 
  # Don't allow static files to set cookies. 
  # (?i) denotes case insensitive in PCRE (perl compatible regular expressions).
  # This list of extensions appears twice, once here and again in vcl_recv so 
  # make sure you edit both and keep them equal.
  if (req.url ~ "(?i)\.(pdf|asc|dat|txt|doc|xls|ppt|tgz|csv|png|gif|jpeg|jpg|ico|swf|css|js)(\?.*)?$") {
    unset beresp.http.Set-Cookie;
  }
 
  # Allow items to be stale if needed.
  set beresp.grace = 6h;
	
  # Allow for Ban Lurker support.
  set beresp.http.x-url = req.url;
  set beresp.http.x-host = req.http.host;
}

In the event of a complete failure the vcl_error sub routine is called. This is used to return a HTML error page to the user, telling them that there has been a problem with the page they tried to reach, which then redirects the user to the home page. Without this in place Varnish will issue a default 'guru meditation' page.

The first part of vcl_error is an optional section that can be uncommented to allow redirection to another domain in case of the failure of the backend server. This can be useful to enable if you want to show the user a nice error page instead of the Varnish issued version, but the site will need to be configured separately. Enabling this also prevents the site redirecting to itself continuously when the underlying site has a problem.

sub vcl_error {
  # Redirect to some other URL in the case of a homepage failure.
  #if (req.url ~ "^/?$") {
  #  set obj.status = 302;
  #  set obj.http.Location = "http://backup.example.com/";
  #}

  # Otherwise redirect to the homepage, which will likely be in the cache.
  set obj.http.Content-Type = "text/html; charset=utf-8";
  synthetic {"
<html>
<head>
  <title>Page Unavailable</title>
  <style>
    body { background: #303030; text-align: center; color: white; }
    #page { border: 1px solid #CCC; width: 500px; margin: 100px auto 0; padding: 30px; background: #323232; }
    a, a:link, a:visited { color: #CCC; }
    .error { color: #222; }
  </style>
</head>
<body onload="setTimeout(function() { window.location = '/' }, 5000)">
  <div id="page">
    <h1 class="title">Page Unavailable</h1>
    <p>The page you requested is temporarily unavailable.</p>
    <p>We're redirecting you to the <a href="/">homepage</a> in 5 seconds.</p>
    <div class="error">(Error "} + obj.status + " " + obj.response + {")</div>
  </div>
</body>
</html>
"};
  return (deliver);
}

The default.vcl that the above samples create is largely taken from work done by FourKitchens and Lullabot to generate a Drupal specific Varnish configuration file. This has been tweaked a little and has been in use in a few production environments for a few months without any problems.

Rather than paste the entire file here I have created a Git repo and placed the default.vcl file there. Feel free to download it and use on your own projects.

For more information about the VCL file take a look at the VCL documentation on the Varnish site.

When setting up the Varnish runtime you can use the -S flag to stipulate the location of a secret file. In the examples above we set this to be at the location /etc/varnish/secret. This is a file that is used as a way of securely allowing administrative access to the Varnish cache. It isn't a required part of setting up Varnish but it helps to lock the system down and so it's a good idea to include it. When a system tries to access the Varnish administration interface it is asked to authenticate. The authentication is sending the contents of the secret file, which Varnish then compares to the actual contents before allowing the connection in.

The contents of a typical Varnish secret file are as follows, but this is generated by Varnish on install.

04788b22-e179-4579-aac7-f3541fb40391

When you have added your own VCL file and set up your Varnish runtime then you need to restart the service in order for these changes to be picked up. This is done with the service command.

sudo service varnish restart

Note that on some Linux systems this might be varnishd.

When you visit your site you should load as it would a normal page request. To see if Varnish has been a part of the request process you need to look at the headers returned from the service. If you see a X-Varnish-Cache header then Varnish is running. It will either have the value of HIT or MISS.

As a quick aside, to inspect the headers being returned from a web request use the curl command with the -I flag.

$ curl -I http://www.varnish.com/
HTTP/1.1 200 OK
Server: Apache/2.2.27 (Unix)
Etag: "1402232119-0"
Cache-Control: public, max-age=0
Last-Modified: Sun, 08 Jun 2014 12:55:19 +0000
Expires: Sun, 11 Mar 1984 12:00:00 GMT
Content-Type: text/html; charset=utf-8
Accept-Ranges: bytes
Date: Sun, 08 Jun 2014 13:09:33 GMT
Age: 0
Vary: Cookie,Accept-Encoding
X-Varnish-Cache: MISS

Configure Drupal

With all this now in place you still need to configure Drupal to communicate with Varnish. If you don't do this then Varnish will assume that every page will miss the cache and so your Varnish cache won't really be running as a cache at all.

To get Drupal to communicate with Varnish you need to install the Varnish HTTP Accelerator Integration module. Once the module is enabled you need to go to the configuration page at /admin/config/development/varnish and set up the Varnish options.

Flush page cache on cron? - I normally set this to 'Disabled' so that Varnish is in charge of the cache. When this is enabled you find that cron runs can frequently empty out the entire Drupal cache, rather than it being done on a page by page basis.
• Varnish version - This tutorial is about installing and configuring Varnish 3. As of now Varnish 4 has been released, but the Drupal module doesn't support this version yet.
• Varnish Control Terminal - This is the location of the Varnish administration interface. This was set when we edited the /etc/default/varnish file and used the -T flag to tell Varnish on which port to setup the interface. As the /etc/default/varnish file sets this to localhost:6082 (which is the default value) you can set the value in Drupal to the same.
• Varnish Control Key - This is the value contained within the Varnish secret file.
• Varnish connection timeout (milliseconds) - Setting this to '100' is fine for a locally installed Varnish server. If you have an external Varnish cache then you might want set this value to be slightly higher.
• Varnish Cache Clearing - This controls what kind of cache clearing should be enabled. The default here is to use Drupal's default cache mechanisms, but you can also install the Expire module to select a different cache clearing system. Setting this to None will allow pages to persist for the full max-age setting.
• Varnish ban type - This selects the type of Varnish ban that is to be used to invalidate objects in the cache. This can be set to Normal or Ban Lurker, which we created support for in our Varnish VCL file.
• Status - If everything has been set up correctly then you should have a notice at the bottom of the page saying 'Varnish running'.
•  
•  
•  

With the module enabled and configured you still need to tell Drupal to treat Varnish as a cache backend. This is done by setting a couple of values in your settings.php file.

// Add Varnish as the page cache handler.
$conf['cache_backends'] = array('sites/all/modules/contrib/varnish/varnish.cache.inc');
// Drupal 7 does not cache pages when we invoke hooks during bootstrap. This needs
// to be disabled.
$conf['page_cache_invoke_hooks'] = FALSE;

If you are using the Expire module then you also need to include the following config option. This sets up a new cache bin for Varnish that can be cleared if needed.

$conf['cache_class_external_varnish_page'] = 'VarnishCache';

If you aren't using the Expire module then you need to include the following option. This replaces the default page cache with Varnish.

$conf['cache_class_cache_page'] = 'VarnishCache';

You might notice that your pages are still not being cached, and there are two reasons for this. The first thing to realise about Drupal and Varnish is that authenticated traffic bypasses the Varnish cache, so if you are logged in then you won't be able to 'hit' the cached versions of pages. If anonymous users are still not seeing the cached versions of pages then you need to enable caching for anonymous users. Go to the performance page in Drupal (located at /admin/config/development/performance) and turn on the option 'Cache pages for anonymous users'. You should now start seeing Varnish cached pages being issued.

Double check things are working by looking at the headers being returned. If the X-Varnish-Cache header says 'HIT' then the Varnish cache was used. You should also see a big speed improvement after the caches have warmed up.

You can also double check that your Varnish/Drupal integration is working correctly by looking at the site Is Varnish Working. This looks to see if the correct headers were generated by your setup and will give you hints on what to look for and change if they weren't.

Apache RPAF Module

One thing you might notice is that although everything here works as a cache system you won't be able to see the IP addresses of your visitors. All of the Apache logs and any IP addresses found within PHP via the $_SERVER['REMOTE_ADDR'] variable will appear to be from 127.0.0.1. This is because the request is coming from the Varnish server and not the end user. The IP address of the user is added to the request headers sent by Varnish and will be in the X-Forwarded-For header. This is a non-standard header and so the user’s IP address is missing from just about everything.

There are many solutions to this, but I have found that the most stable is to use an Apache module called Reverse Proxy Add Forward (also known as RPAF). To install this use the following apt-get command.

sudo apt-get install libapache2-mod-rpaf

If the module isn't already enabled you can enable it with the following command.

sudo a2enmod rpaf

All that is left to do is to edit the RPAF configuration file at /etc/apache2/mods-enabled/rpaf.conf. This file contains a few different options, but essentially all you need to have is the following:

RPAFenable On
RPAFsethostname  On
RPAFproxy_ips    127.0.0.1 192.168. 10.0.0.
RPAFheader       X-Forwarded-For

The configuration options set here are as follows:

There are one or two other options available here, but I have found that they aren't fully supported on all platforms. Don’t try and solve this IP address problem by getting Varnish to pass the user’s IP address as the request IP address as you won’t be able to lock down the Apache port listener to just local traffic.

With this config file in place you need to restart Apache for the change to be loaded. You should instantly see a difference in your Apache access logs and within the Drupal watchdog logs.

If you are using Centos then most of the previous steps will be pretty much the same. (aside from some of the default the file locations). The install of RPAF is slightly different and requires grabbing the precompiled version from github and installing using Yum. The following command will do this.

sudo yum localinstall http://y-ken.github.com/package/centos/6/x86_64/mod_rpaf-fork-0.6-5.el6.x86_64.rpm

Finally, Varnish is a really good way of speeding up a Drupal site, but it isn't a plug and play solution for every situation. You should read through the VCL file and understand everything that it is doing, and any implications that this might have on your site. It’s important to realise that if you run a login only site or an ecommerce site then Varnish will probably only work for a small percentage of your users. It is possible to allow Varnish to work with authenticated traffic but you’ll need to look into something called Edge Side Includes (EDI) so that you can poke holes into your Varnish cache layer to display customised user content.