Four steps to a sleek and speedy Drupal

A 4 minute read written by Adam June 4, 2015

An illustration of a Drupal logo with a stop watch beside it.

Dear Drupal, We need to have an honest conversation. Your flexibility and versatility are unmatched in the open source space. But at what cost? The server load you generate on the simplest of web sites.

Oh, you’re scalable all right. With the thousands of community written and supported modules the sky’s the limit — for developers. What about an infrastructure guy like me? Just look at all these steps I have to do to make you sleek and speedy. OK, it’s just four steps, but that’s not my point! Keep reading to understand all the effort it takes for me to make this relationship work.

a screenshot of a terminal window with code

Step 1 – Drupal cache

Let’s first knock off the low-hanging performance fruit. Inside Drupal, jump to admin/config/development/performance. We’re going to enable all the caching options as well as compress and aggregate JavaScript and CSS. Then we’ll set the minimum cache lifetime to 5 minutes. Essentially, this instructs Drupal to deliver a page from the assembled cache for at least 5 minutes, regardless of whether the page has actually been modified by anyone. On relatively static websites, such as brochure or marketing sites, you can explore a much larger cache window since the pages aren’t likely to change often.

a screenshot of Drupal admin configuration

Step 2 – enable OPcache

If your Drupal site is powered by PHP 5.5 — and chances are it is — you should know that opcache is now baked in. OPcache will precompile PHP scripts and store the resulting bytecode in memory. While it’s not enabled by default, it’s rather straightforward to flip the switch.

sudo vi /etc/php5/apache2/php.ini

Add the following:

opcache.enable=1
opcache.max_accelerated_files=1024
opcache.memory_consumption=128
opcache.revalidate_freq=60

Kick Apache with sudo service apache2 restart to apply the changes:

a screenshot of a terminal window with code

Step 3 – Memcache

Thus far, we’ve effectively leveraged our existing installation and environment. And that’s great: the performance of Drupal cache with OpCache can generally take you most of the way, especially if your site consists of anonymous user traffic.

Unfortunately, Drupal cache isn’t super helpful when it comes to authenticated, or logged in, user traffic. At this point we really need to ease the burden on the database if we want to squeeze a bit more performance out of the stack. Enter Memcache.

Memcache is an intercepting layer between PHP database calls and the database backend. Queries and results are captured and stored in-memory. For the right sites this can have a dramatic effect on performance. But again, it’s not for everyone. Here’s what we do:

  • Execute sudo apt-get install memcached php5-memcached
  • Download and install the Drupal Memcache module
  • Add this snippet to sites/default/settings.php
    $conf['cache_backends'][] = 'sites/all/modules/memcache/memcache.inc';
    $conf['memcache_servers'] = array(
            '127.0.0.1:11211' => 'default'
    );
    $conf['cache_default_class'] = 'MemCacheDrupal';
    $conf['memcache_key_prefix'] = 'a_unique_key';
    
  • Again, kick Apache with sudo service apache2 restart to apply the changes and start Memcache with sudo memcached start.

a screenshot of a terminal window with code

Step 4 – Varnish

And obviously I’ve saved the best for last: Varnish. If you think of Memcache as your backend caching layer, Varnish fulfills the same need for your frontend. That is, web requests from your users travel to Varnish before being passed, if necessary, to your Apache layer. Varnish is ridiculously fast at serving cached requests and it’s the secret sauce in almost all high-performance Drupal sites. Let’s dive in:

  • Execute sudo apt-get install varnish
  • Varnish configuration is controlled by two files:
    • /etc/default/varnish
      • Modify the DAEMON_OPTS block for the Varnish listening port (-a :80) and the memory allocation (-s malloc, 64m)
    • /etc/varnish/default.vcl
      • At Yellow Pencil we start with a default.vcl according to this setup as the foundation is suitable for most setups. However, ensure you adjust the backend block and set the port to where Apache lives - 8080 in this case.
  • For Varnish to live and respond to requests on port 80, Apache must be reconfigured to bind to the backend port defined previously — 8080.
    • Execute sudo vi /etc/apache2/ports.conf
    • Change the Listen directive from 80 to 8080
    • Kick Apache sudo service apache2 restart
  • Start Varnish with sudo service varnish start
  • Download and install the Varnish Drupal module
  • Under admin/config/development/varnish adjust the Varnish version to 3.x and set the Varnish Control Key to the value defined in /etc/varnish/secret. Incidentally, it’s a good idea to change this value from the default!
  • Save configuration and look for Status: Varnish running within the interface
  • Add this snippet to sites/default/settings.php
    $conf['cache_backends'][] = 'sites/all/modules/contrib/varnish/varnish.cache.inc';
    $conf['cache_class_cache_page'] = 'VarnishCache';
    $conf['page_cache_invoke_hooks'] = FALSE;
    $conf['omit_vary_cookie'] = TRUE;
    $conf['reverse_proxy_header'] = 'HTTP_X_FORWARDED_FOR';
    $conf['reverse_proxy_addresses'] = array('127.0.0.1');
    
  • You can verify Varnish is doing its magic with sudo varnishstat and watch your Hitrate ratio climb as you refresh the website in your browser.

a screenshot of a terminal window with code

If you’ve made it this far your reward will have been a super scalable Drupal site in just over 15 minute. Not a bad use of your time, eh? Thanks Drupal. I’m glad we’ve had this little chat.

Do you have any other ideas on how to power-up Drupal? Share them in the comments or send me an email.