Learn some basic Drupal optimisation tricks for anonymous visitors of your Drupal site.

Advanced Drupal optimisation techniques

Cacherouter

It’s the situation when Cacherouter could help us. This module allows replacing default Drupal caching system by more flexible caching system, which allows you to use several backends:

• APC
• Database
• eAccelerator
• File
• Memcache
• XCache

If you have no rights to install additional software on the server, such as apc, eaccelerator, memcached, etc, you can still speed up your cache by using “File” backend for cacherouter.

Installation and configuration of cacherouter could be done in 2 steps:

• Enable the module in admin/build/modules.
• Setup your settings.php

Let me put an example of a configuration for File backend:

First of all, you need to tell Drupal to use your common caching system by specifying custom cache_inc file:

$conf['cache_inc'] = './sites/all/modules/contrib/cacherouter/cacherouter.inc';

Next you need to configure your backend:

$conf['cacherouter'] = array( 
  'default' => array( 
    'engine' => 'file', 
    'servers' => array(), 
    'shared' => TRUE, 
    'prefix' => '', 
    'path' => 'sites/default/files/filecache',
    'static' => FALSE,
    'fast_cache' => TRUE
  ));

By doing this configuration, you’re telling cacherouter to use fo all cache bins (cache, cache_views, cache_menu, cache_form, etc...) to use files, that are located in sites/default/files/filecache directory. You can specify different backends for different cache bins by adding new array item with the name of cache bin as a key. For instance you may use db for cache_menu and file for others.

$conf['cacherouter'] = array( 
  'default' => array( 
    'engine' => 'file', 
    'servers' => array(), 
    'shared' => TRUE, 
    'prefix' => '', 
    'path' => 'sites/default/files/filecache',
    'static' => FALSE,
    'fast_cache' => TRUE
  ), 
  'cache_menu' => array( 
    'engine' => 'db', 
    'servers' => array(), 
    'shared' => TRUE, 
    'prefix' => '', 
    'path' => '',
    'static' => FALSE,
    'fast_cache' => TRUE
  )
);

Make sure that specified directory is writable by webserver.

Drupal cache tables’ explanation

Now lets see how each cache table (bin) is used in Drupal. Right after installation, clean Drupal is shipped with 5(6 - if module Update status is enabled during instalation) cache tables:

• cache - is used for all common cache purposes. is a default cache bin for Drupal.
• cache_block - is used for storing block’s cache
• cache_filter - is used for storing filtered input
• cache_form - is used for storing forms
• cache_menu - is used for storing assembled and processed menu
• cache_page - is used to store cached pages 
• cache_update - if module “Update status”  is enabled this bin stores Drupal, modules and themes update information. 

Among this, there are several other bins, that come with appropriate modules. Lets review common modules, that provides their own cache bins:

• CCK - cache_content - used to store cck-related information (field information)
• Views: cache_views - is used for storing view object & cache_views_data - is used for storing query results and/or rendered output

What else can we do to improve site performance?

Using Elysia Cron to reduce cron impact

Drupal’s cron feature is the powerful tool to run heavy tasks in background through hook_cron. But this core feature has some limitations though, such as:

• All hook cron implementations for all modules are run at the same time, in sequence, alphabetically or according to module weight.
• When cron for one module is stuck, all modules following it will not be executed, and cron will not run again until 1 hour has passed.
• There is no way to know which module is the one that caused the entire cron to get stuck. Moreover, there is no instrumentation information to know which cron hook takes the most time.

With Elysia Cron module you can set up interval for each hook_cron implemented on the site, see what cron task is consuming most of the time, reorder your cron tasks, disable cron tasks and more. This gives you flexibility to speed up cron execution. You can read more on Module page

Last things to do are...

When we’re done with all Drupal-side optimisations, it's time to dig into optimisation of server environment. The first thing to do is to setup Memcached caching. As i have already mentioned, we are using Cache Router for managing caching of the Drupal site. Lets set it up to use Memcached as the backend engine. As long as Memcache uses RAM for storing data - this engine is extremely fast. The main purpose of memcached is to store cache bins in memory

To achieve this goal its enough to configure Cacherouter, as described above with small difference:

$conf['cacherouter'] = array( 
  'default' => array( 
    'engine' => 'memcache', 
    'servers' => array(127.0.0.1:11211’, ‘127.0.0.1:11212’), 
    'shared' => TRUE, 
    'prefix' => 'your_site_name_prefix', 
    'path' => '',
    'static' => FALSE,
    'fast_cache' => TRUE
  )
);

Here we stated, that we’ll use memcached as backend and will use 2 instances, which are located at 127.0.0.1:11211 and 127.0.0.1:11212. Of course, you have to set up these instances at your server. They may have different IPs and ports than described above. Prefix is used to separate different caches from each others. For instance - you may have several projects, which use same memcached instances. Sure thing you may still use different backends per cache bins.

Commonly you will need the following set of bins and instances:

default: for cache, cache_views, cache_update. Should be 256 MBytes in size.

menu: for cache_menu bin. Should be 64 MBytes in size.

content: for cache_views_data, cache_content, cache_page bins. Should be 64 MBytes in size.

block: for cache_block bin. Should be 64 MBytes in size.

filter: for cache_filter bin. Should be 64 MBytes in size.

form: for cache_form bin. Should be 64 MBytes in size.

This is it for anonymous Drupal optimisation.

Next tutorial will be about auth drupal optimisation, with varnish+esi, authcache