Drupal performance tips

What really works to improve Drupal performance? Here are the inside tips based on real world experience and presented with the easiest quick savings first.

1. PHP cache
2. MySQL settings file
3. Drupal cache
4. Module selection
5. Access time recording
6. Boost add-on module
7. Proxy server

PHP cache

Killer performance tip number one is to use a PHP cache. This step should be obvious to everyone who uses anything based on PHP but so many people spread so many ridiculous rumours about PHP cache software that a lot of people place PHP caches well down on their list of things to do.

PHP is an interpretive language the same as dozens of other languages including Javascript and Java. Interpretive languages were around 20 years before PHP was invented. I wrote a couple myself. The first thing you realise is, interpretive languages spend a lot of time repeating the same interpretation.

The first thing you do as the developer of an interpretive language is to create caches for interpreted code so you do not repeat the slow interpretation. When I wrote my first interpreter, I included caching of intermediate results. I found a bunch of other interpreters contained similar approaches. PHP was strangely late in developing a cache and several were developed in parallel.

Some PHP cache applications wasted time on code reordering tricks, which are almost always unreliable, and that gave people the impression that PHP cache software creates problems. You get the maximum benefits from basic caching of PHP code. leave all the tricks switched off.

APC is on PHP 6. Use APC for PHP 5. eAccelerator is almost as fast and as reliable and is the default in cPanel for some Web hosting accounts. If eAccelerator is the default for your Web hosting, use it instead of stuffing around trying to switch to APC.

XCache is a new kid on the block and has not proven to be significantly different. If your Web host uses XCache, use XCache. If your Webhost uses APC or eAccelerator, use what they recommend and support.

Nusphere PhpExpress and Zend Optimizer are alternatives that decode specially encoded PHP files. You would only use them for encoded proprietary applications.

MySQL settings file

MySQL settings are in a file named my.ini or my.cnf. MySQL provides a bunch of samples with names including my-small.cnf, my-medium.cnf, my-large.cnf, and my-huge.cnf. Choose one. MySQL, by default, almost always chooses one that is too small. Try the next one up in size and measure the difference.

During the typical MySQL Windows install, MySQL asks if you want a development system, a server, or a dedicated MySQL server. The development option always uses a trivial amount of memory and runs slow when you access a lot of data. I have an XP based development machine where there is six or more GigaBytes of memory unused while MySQL grings through millions of rows of data in some trivial memory allocation.

You can change individual memory settings one at a time. The individual settings approach takes a lot of time and many of the settings have no affect unless used together with a lot of other changes. Save time and jump to the next size up .cnf file. measure the result. Is it better or worse? Use the largest .cnf file that does not slow down your Web site.

After you change to the right size .cnf file, you might tune some individual settings. There are about six of importance. You can tell which are important because they have the biggest increase when you step up to a bigger .cnf file. Leave the tuning of the individual settings until after everything else. Wait until you know a lot about your Web server usage, your database, and what the individual settings mean, and until you have a server with more memory.

See more details in MySQL performance tips.

Drupal cache

Drupal has a built in cache system to make some things faster. There are settings in the administration area to control the caches. Start by switching on every cache.

Drupal will warn you about some cache settings that do not work with certain modules. Switch off any settings that conflict with your choice of modules then review your choice of modules. There might be a better choice that lets you use more caching.

When you are developing a theme, temporarily switch off caching of CSS and pages. Do the same when developing modules. Make sure you switch everything back on when you finish development.

Module selection

A lot of Drupal module selections are based on fashion or a desperate grab at the first module to do what you need done. There is often no choice because of the several modules listed as providing the same feature, some are unsupported, some are still in beta or alpha development, and some do not do what they are described as doing. You are left with one choice.

Six months later there could be other choices ready to use and some might be faster. Review your choices on a regular basis, at least once per year.

Review module options. Some options dramatically increase the amount of data processed. If you are not using the data, do not process it. Talk with other users of the same modules. Search for the module name and performance.

Consider raising performance issues against modules. If you know how databases work and the range of database activity generated by a module, you might be able to suggest an improvement. If you do not know how databases work, or how to tune databases, ask people like me to help. Every module should have a performance issue raised for each major release of Drupal to ensure the module makes maximum use of drupal performance features.

Access time recording

This is something weird that applies to every Linux or unix based computer and should be switched off by default.

Linux and Unix can record the time of last access for a file. The Linux Ext2, Ext3, and Ext4 all have the option and all have the option switched on by default. Switch it off.

The easiest way to switch it off is to set the noatime option for a disk partition when allocating disk partitions. Put this on your list of things to do when building your next server.

If you find an easy way of switching off access time recording for the file system in your version of Linux, switch it off. The disk utility in Ubuntu does not let you switch off access time recording. There might be other ways.

Boost add-on module

The Boost add-on module, from drupal.org/project/boost, might help you deliver some pages faster. Consider all the negatives then consider Boost.

Boost makes copies of pages as HTML files for delivery to anonymous users. Boost does nothing for logged in users and they are often your priority. With a bit of luck, Boost might reduce the anonymous traffic overheads enough to leave more resources for your logged in users.

Boost is replicating what a proxy server does. Fixing your proxy cache settings in your Web pages has far more benefit.

Boost only works for the HTML download. Boost does nothing for other content. Images and other files often create far more network overhead than the HTML traffic. Look at moving large content files to replicated servers for easier content deliver

If a file is delivered from HTML, the access is recorded in your Web server log, not Drupal statistics. Review your statistics recording and reporting before switching on Boost.

As soon as you finish the complicated installation of Boost and alter all your usage recording, someone will recommend varnish and you will have to change everything again. (Varnish is a glorified proxy server).

Proxy server

Varnish is the most fashionable HTTP cache among Drupal evangelists. Varnish does exactly the same thing as a proxy server. There are minor technical differences. You have to step through the hype to find the reality. If your web hosting provider provides a proxy service, use theirs.

When does Varnish and it's equivalents slow down your Web site? You might be sharing a server by using a VPS, a Virtual Private Server, and be limited to just enough memory to run your Web site. Adding Varnish means adding another application and trying to squeeze more more data into memory. your web site might slow down due to paging or crash due to timeouts. your web hosting company might provide a proxy server on a separate server giving you the benefit of caching in memory without using any of your memory.