Tips on speeding up your Drupal sites

We get asked a lot how to make a Drupal site faster. Therefore, we list here some tips on how to achieve such a goal.

These guidelines apply for sites that start to pick up traffic (e.g. more than a few thousand page views a day).

If you have tips to share, please add them as a comment below.

Avoid shared hosting

Shared hosting means that you cannot control, let alone know, the load other web sites impose on the server you are hosted on. Moreover, you cannot tune things such as database variables, nor install additional components (e.g. a PHP accelerator).

So, unless your site receive a few thousands page views a day, avoid shared hosting altogether.

Go for VPS or dedicated servers

With shared hosting eliminated from the picture, you are basically left with either a VPS (Virtual Private Server) or a dedicated server. A VPS is an reserved slice within a real dedicated server that you control yourself, i.e. you have root access, can install any software you like, ..etc.

VPS based on Xen are very cost effective, and provide excellent performance, provided you have enough memory.

At what point should you move from a VPS to a dedicated server? It is hard to say since each site is different, has different module, has different usage pattern, ...etc. But as a general imprecise rule, a VPS should be able to handle up to 50,000 to 75,000 page view per day with acceptable performance. Above that, and you are better off with a properly configured dedicated server with appropriate memory and CPU.

Install as much memory as you can afford

Memory is cheap compared to the expense invovled in hand tuning and squeezing the most out of a limited memory machine. The extra memory not only allows extra Apache processes to run so that you can handle traffic spikes gracefully, but it also buffers the filesystem and the database, so disk I/O is avoided altogether, and queries are fast.

Avoid dedicated with shared database hosts

Some VPS / dedicated hosts do not give you the option of hosting MySQL on your dedicated server itself, and force you to have the database on a separate server, shared with other databases of other servers! This is a very bad setup for a medium to large Drupal site, since Drupal does a lot of database queries per request. If the database server that is assigned to you serves other busy web sites, your VPS / dedicated server will sit idle waiting for the database requests to be served, and your site will be slow.

Dreamhost is one company that forces the database to be on a remote server. Here is a recent example of how an increasingly popular web site was bogged down because of that architecture.

Use a PHP Accelerator/op-code cache

Using a PHP accelerator (op-code cache) is a must for medium to large web site. The popular free ones are APC, eAcceleartor and Xcache. Each has its pros and cons, and depending on the version(s) of PHP you use, some may be more stable than others.

Enable MySQL query cache

The single most important MySQL factor for large sites is a well tuned MySQL query cache. MySQL will store the results of queries in a cache so subsequent requests to get served by, bypassing the need to re-run the queries.

Make sure you have MySQL's query cache configured with an appropriate size.

Avoid the open buffet syndrome for contributed modules

With so many modules available for Drupal, site admins/builders are tempted to install too many of them, either to try them out, or to have extra cool features offered by said modules.

The down side is that additional modules add to the size of each Apache process, consuming more memory. Moreover, most modules have their own database tables, and cause more queries to be done, adding some overhead.

As well, some modules have untuned non-scalable code, that buckles down under heavy load.

So, avoid using extra modules as much as you can. Failing that, use modules that are proven to be scalable.

Enable Drupal caching

Drupal has a built in cache mechanism. Some of that cache is always on, and cannot be turned off (e.g. menu, filter and variable caches). The page cache is optional and, for anonymous users, collapses many database queries into one query.

So, if your site has a large proportion of anonymous to registered visitors, enable the page cache. For more performance you can also consider the aggressive cache as well.

Consider file based caching (boost)

There is a file based caching module called boost that stores the cached pages in flat files outside the database. This causes anonymous requests to be served directly by Apache from the file system, and thus avoiding Drupal's bootstrap and database I/O altogether.

Use this module if you know how to setup Apache .htaccess.

Use memcache if you know how to set it up

There is a memcache module which causes the Drupal cache to be in memory rather than in the database, thus avoiding database and disk I/O overhead.

Setting up this module for Drupal 5 is a bit involved, but if you are brave enough, it is worth the effort.

Read articles at 2bits.com

There is much more to be said about performance of a Drupal web site.

2bits posts regular performance tuning and optimization articles. So, go and read about the above points, and much more. You can also subscribe to our articles feed to get these documents as they get posted.

Hire 2bits to tune your Drupal web site

As part of our Drupal consulting services, 2bits offers a performance tuning and optimization service. Use the Contact link to ask for an engagement.