Caching Overview

Last updated on
17 February 2017

In order to maximize performance of Drupal we need to understand all the spokes in the wheel that makes it run. Drupal is comprised of many layers that all come together, many of which are outside of the software itself.

Caching layers

There are two main types of traffic that Drupal can receive, each with very distinct performance attributes.

Authenticated Users generally see pages that are dynamic and unique to them. They are more challenging to cache.

Anonymous Users are generally served a version of the page that doesn't change between users. These pages can be fully offloaded to a cache.

It's important to understand the type of site you have and the type of users coming to your site.

For a lighter user, the section Basic Configuration should handle most use cases.

Heavier users may need more complex configurations to handle load and performance.

Basic configuration

Drupal offers basic performance tuning at:
Administration > Configuration > Development > Performance (admin/config/development/performance)

It is recommended that block and page caching be enabled. Instead of Drupal dynamically performing complex SQL queries it caches these for quick retrieval.

If you enabled caching, remember, you may need to Flush Cache (Clear all caches button) to see any changes made to your site. The Devel module makes this option part of your top menu for quick cache flushing. If you're a more technical user look at Drush. You can flush cache with one shell command drush cc all.
Typically during development, caching should be disabled. On production sites, caching should always remain enabled for best performance.

Page and block caching is not always available. For example, page caching will not be available when a component of the page has marked the page as explicitly not cacheable, such as using sessions. Block caching will not be available when using a module that utilizes node access, such as Organic Groups or Taxonomy Access Control Lite.

Performance Areas

Opcode Caching (PHP - high CPU)

PHP out of the box is a dynamic language and can lead to heavy CPU usage on web servers. There are multiple types of opcode caching add-ons for PHP available that will convert your .php page into memory (byte code) to provide a major benefit in load time and reduced CPU usage. Each of these will require root access to install and have their own specific configurations that will need some attending before using. Once configured and enabled they can provide a substantial benefit to a slow site and greatly reduce CPU usage from PHP.

Wikipedia has full list of other Opcode cache technologies for PHP.

Database Caching

Database caching can be provided by a distributed memory object caching system, such as Memcache. Memcached allows you to allocate memory where you have more than you need and make it accessible to areas where you have less than you need. When implemented with Drupal, Memcached can store the result of your database query’s in the memory for a specified time, reducing database traffic.

Web Server (Proxy) Caching

HTTP acceleration, or Web Server (Proxy) Caching, will significantly reduce resource requirements and page load times. Varnish Cache, is a widely-used HTTP accelerator for Drupal sites.

HTTP acceleration is handled by a reverse proxy. A reverse proxy is a type of proxy server that retrieves resources (pages, images, files, etc.) prior to being requested by a website visitor. These resources are stored in virtual memory and are quickly retrieved by the proxy server when requested. Reverse proxies are heavily threaded and optimized for data retrieval.

Authenticated Users

Performance Modules

If better optimization is required, you might install one or two performance modules. For example, if the site is on a shared server, try Boost (static page caching for non-logged in visitors), complemented with Authcache -in CR's file (for logged in members). If on a VPS or dedicated server, there are several suitable options: Boost (for example on a low RAM VPS), Authcache, Cache Router (which includes , Memcache...), Varnish, etc. Memcache (or Memcache Storage) and Varnish are also especially suitable when load-balancing multiple servers.

For extensive and detailed information, and more options on server optimization for Drupal, see the following selection of resources.

Drupal performance resources

Information and tutorials on optimizing Drupal's performance, speed, and scalability.

General Drupal performance


  • High performance - Drupal group dedicated to solutions and approaches for high traffic, high performing Drupal sites.
  • Modules: Performance and Scalability - Contributed modules: Advanced cache, Authcache, Block Cache Alter, Boost, Cache browser, CacheExclude, Cache Router, CSS Gzip, Javascript Aggregator, Memcache, Path Cache, Term lower name, Varnish, etc. The list can be ordered by usage statistics, last release...
  • Caching: Modules that make Drupal scale - Wiki page for comparison of performance and scalability modules.
  • Server tuning considerations - Detailed collection of HowTo pages.
  • Compatible with Memcache module? - Boost module issue including a solution to use several performance modules working together for logged in and non-logged in users.
  • System: cron and caching - System, a required core module, provides system-wide defaults for storing (caching) web pages to improve efficiency, and performing other essential tasks.
  • Throttle: congestion control - Throttle, an optional core module, provides a congestion control throttling mechanism for automatically detecting a surge in incoming traffic. (Throttle was deprecated in 7.x.)
  • Coding Standards and Performance Optimization - Group for Drupal developers, on optimized PHP coding.
  • Performance and scalability - Deprecated forum with old threads; for current discussions see the two performance groups, specially High Performance for Drupal sites.
  • Load Testing Drupal - A module that generates customized Apache JMeter and Selenium test scripts for any Drupal installation. These scripts are ready to run as part of a load test on a load testing cloud provided by BlazeMeter.

Other resources:

Videos, screencasts and slideshows


Other resources:

Case studies


Other resources:

Monitoring and troubleshooting


Other resources: