Several advanced options exist to take caching to the next level in Drupal. With advanced caching Drupal is able to scale to levels required by the most demanding of sites.

We have already discussed (i) page and block caching and (ii) other caches which come baked into the core of Drupal in the Out of the Box section. Whilst big gains can be made through enabling simple config options it is possible to make several more improvements to the way Drupal caches and serves data, making Drupal a system which can scale to serve 1000s of requests a second if the need arises.

Page Caching

The Bootstrap

Every time Drupal code needs to be run either through a web page or script, Drupal must undertake the boostrap process which has a certain amount of overhead. Generally this process cannot be avoided – you need to run code after all. However, there are a couple of cases where it is possible. Firstly, Normal Page caching avoids much of the bootstrap save for hook_boot() and hook_exit() hooks which are used by the statistics and throttle modules. Secondly, Aggressive Page Caching allows for all of the bootstrap to be avoided when serving content. Finally, contributed modules such as Boost and Varnish allow for the avoidance of PHP and bootstrap since they are operating at a stage before PHP is invoked. This is the main reason Boost and Varnish are so attractive as a page cache.

Boost

Boost is a page cache which works in a similar way to aggressive page caching in that it attempts to serve cached data without running the bootstrap. However, it is able to go one step further and avoid PHP being run as the redirect takes place in rewrite rules located in .htaccess. If the static file exists then it is served as the response. The end result is super fast response without running PHP or the bootstrap. This frees up the server to handle more requests from logged in users.

Boost is an attractive module because it is easy to install, has a lot of configuration options which give good control over cache building and invalidation. It is highly recommended.

One aspect of Boost which may be forgotten is that it isn’t an entirely a file based solution. If the operating system file cache is working well then there is a good chance that the “file” will come out of RAM rather than off disk. This makes Boost a competitive option when compared to other more complicated reverse proxy setups such as Squid or Varnish.

Because Boost is file based it is able to potentially cache a lot more data than a RAM based solution. If you have thousands or millions of pages to cache putting them all in RAM is probably not optimal. Best to put them on disk and save the RAM for DB indexes or possibly a CacheRouter cache.

All sites, especially big, infrequently changing, high traffic: Big gains. Easy setup.

Varnish

The Varnish HTTP Accelerator Integration module integrates Drupal with Varnish, a reverse proxy which sits in front of Apache, PHP and Drupal. Varnish stores cached content in RAM and avoids the overhead of Apache and the Drupal bootstrap. As such it offers very high performance for anonymous users on cached pages and is the preferred option for many sites where scaling is paramount.

Varnish requires either a patch to core to add HTTP headers, PressFlow or Drupal 7. Most people are therefore running Varnish in conjunction with PressFlow.

High Traffic: Big gains when performance critical.

Squid

Squid is a reverse proxy similar to Varnish and is in use on drupal.org. It doesn’t seem to be such a commonly deployed solution probably because PressFlow has been altered to work with Varnish which is higher performing apparently.

Varnish preferred over Squid.

Varnish vs Boost

A popular thread High Performance Drupal group is for the perfect recipe for page caching – whether to use Varnish or Boost. Varnish has the edge in speed over Apache+Boost as well as Nginx+Boost. Look at results published by brianmercer.

Varnish may have the edge in speed but it is more complex to install and requires a patched core. Some people may not want to run a non standard Drupal installation. Varnish also requires RAM to store the cached material – something which may be better spent elsewhere (database or max clients). Boost offers similar performance, is easy to install and has good control of cache invalidation and warmup. Boost is also able to serve files from RAM if the OS has cached them.

It is certainly up to you to decide which avenue to take. This guide is attracted to the relative simplicity of Drupal + Nginx + Boost over Pressflow + Varnish + Apache/Nginx. Nginx brings better performance to the web server as a whole, ie. pages not in the cache, and RAM savings if it is needed elsewhere. It must be stressed that each site has a different profile and the ultimate decision is up to you.

Has anyone tried nginx caching with Drupal?

Drupal Groups thread with lots of benchmarking. Final conclusion seems to be that Varnish vs Boost+Nginx is a pretty close thing.

Project Mercury: A pre-configured Drupal+Varnish EC2 AMI

Josh Konig of Chapter Three claims that Varnish is faster than Boost but gives no numbers.

Quick Drupal Cacherouter and Boost benchmarks

Dylan Tack likes Boost: “Response times are all close enough that it doesn’t really matter what caching backend you choose… The only factor that’s really relevant is how good your system’s cache expiration and regeneration logic is… it seems like Boost is the clear winner here as well.”

What’ recipe should i choose for best performance?

Discussion with participants split between Varnish and Boost depending on circumstances. Nginx+Boost seems pretty equal with Varnish.

Caching: Modules that make Drupal scale

Table of modules, performance gains and features.

Cache Router

Cache Router is a module which enables you to cache the Drupal cache tables (including views, blocks, menus, variables, and filters) in RAM. Drupal no longer has to hit the database to pull out this content – a big win for logged in users who might not be able to enjoy the advantages of a page cache. Cache Router therefore fills an important niche in your caching strategy.

Cache Router is able to do this via a number of backends including APC or Memcache. APC should be considered if you are running Drupal on a single node and only need the single local store. According to Josh Konig, APC “is less error-prone, more secure, and allegedly as fast (if not faster) than running memcached according to the folks at Facebook.” Memcache can be used to share cached data between or across multiple servers.

High Traffic, Logged in: Massive gains when page cache not hit.

This article forms part of a series on Drupal performance and scalability. The first article in the series is Squeezing the last drop from Drupal: Performance and Scalability.