The following provides a range of areas where performance can be improved by using various caching options or server architecture improvements. We assume here that your SQL queries and the web application code are already optimised for performance. There are a number of options outlined below that will assist with supporting load surges. Our usual recommendation is to mix a variety of caching approaches with load balanced web application servers and a persistent DB and file system server.

Option 1: Manage your Drupal cache

Drupal stores all caches in the database (which will is ideally stored via memcached, see below).

The caching strategy can differ from site to site, but these are the likely configurations you would enable:

• Cache pages for anonymous users (cache_page)
• Cache blocks (cache_blocks)
• Cache (cache)
• User sessions (sessions)
• Compress pages
• Aggregate and compress CSS files
• Aggregate JavaScript files

The minimum cache lifetime and the expiration of the cached pages should be set according to the needs of the site (eg 30 min).

Some modules offer additional caches to reduce the execution time of pages, these are essential to set. For Example:

Module views- Caching query results
- Caching the display rendering
- Caching views blocks

Module panels- Caching panels on pages

Option 2: Install and use Varnish caching

Install Varnish, which is an HTTP accelerator designed for content-heavy dynamic web sites (ref: www.varnish-cache.org).

Option 3: Install and use Memcached

Using Memcached is recommended to deport the Drupal cache from Drupal MySQL database, which is usually already highly stressed, to dedicated infrastructure (ref: http://memcached.org/)

Option 4: Install and configure as required, additional Drupal cache modules

Memcache – http://drupal.org/project/memcache
Recommended: useful for the administration and implementation of the Drupal cache storage in memcached.

Cache Actions – http://drupal.org/project/cache_actions
Recommended: Allows smart cache invalidation and management

Varnish – http://drupal.org/project/varnish

Auth cache – http://drupal.org/project/authcache
Recommended: offers page caching for both anonymous users and logged-in authenticated users

Performance hacks – http://drupal.org/project/performance_hacks
Helpful but not necessary: provides specific improvements in performance.

Entity Cache – http://drupal.org/project/entitycache
Highly recommended: activate cache for Drupal entities.

Path Cache – http://drupal.org/project/pathcache
Highly recommended: activate cache for paths

ESI API – http://drupal.org/project/esi_api
Not recommended because of few users and community activity. However, it uses the menu router ‘theme callback’ and ‘delivery callback’ for integrating to core, which makes the approach efficient and comprehensible (no exit() in AJAX/ESI callbacks).

Option 5: Use MongoDB instead of MySQL

Using MongoDB can be considered as alternative storage backend for MySQL.  This option is effective but it is not suitable for every project if you don’t have time to configure everything correctly.

MongoDB is a relatively young product and the possible impacts on development processes can be very high. Retaining skill sets for support and maintenance periods also needs to be considered.

Option 6: Configure architecture to use multiple load balanced web application servers

Link is an advanced consulting partner for Amazon Web Services and has established a number of hosting environments for Drupal sites. Our best practice approach is to have a dedicated DB server with a volume mounted as an NFS (this instance can also be used for SMTP). The NFS contains all code and user uploaded files such as images and PDF documents.  A web application server is then created as a template and configured to scale horizontally within an auto scale group (ASG).

Using a dedicated NFS also helps with the deployment of new code as production web application servers do not need to be updated outside of regular OS or application patching.

Option 7: Vertically scale server infrastructure

Link built, hosted and supported hackerspace.govhack.org using a minimally customised Drupal Commons 3 distribution. The Hackerspace site was highly active for a three day period but received additional traffic in the last hour of the competition deadline. To meet the additional load we scaled up the AWS instance from a single medium server to an extra large when we reached a 75% utilisation rate. Unfortunately, the method required a three minute outage during a high load period to scale up the single server. Such a solution would be suitable if a planned outage for a few minutes could be undertaken prior to an event which is expected to generate high load.