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.

Contents: 

Comments

Is there a VPS provider (or

Is there a VPS provider (or set of providers) you recommend? I have heard conflicting reports that with these you may run into similar issues you would run into with shared hosting.

I can't speak for Khalid...

... but I'd take a look at either SliceHost or Linode. Both offer low cost "DIY" Xen based VPS hosting. I am a happy SliceHost customer. I came from a shared hosting background and found that their articles section was just what I needed to get going. Most of the tutorials on SliceHost and 2bits focus on Ubuntu, making them complimentary. Best of luck Ken!

Slicehost is good

Slicehost is definitely good.

The technology they use is good, and their support is good too.

They have been purchased by Rackspace though. Not sure if this will change things or not. Hopefully not.

annier

My drupal sites was very slow and I have tried many ideas to boost up the speed but none works and finally I found the tips from your site.I am proud to claim the fact that it works and now my system is too fast.

It's ironic I came across

It's ironic I came across this article while looking for ideas on improving drupal performance as I work as a sysadmin for a small hosting provider.
I think your points are well made but they depend on a premise that hosting providers don't care about individual web sites and don't want to provide the best for their clients. Maybe that's the case. In our case it's not I'd say and hope. There are actually a couple of good things about using a shared hosting provider.

re: avoid shared hosting

I disagree with that and my best performing site is on a shared hosting provider. The downside of using a VPS is having to administer the dang thing, which means you have to know your stuff. Especially considering the number of rogues out there looking for undefended servers to take over. e.g. On my previous VPS there was a constant stream of inbound ssh requests trying to get root access fortunately they never seemed to get in but it's clear that rogues are out there. Being a sysadmin can distract one from ones core purpose for running a site. A lot here depends on the size of your operation. If you're meaning to serve 10,000+ visitors an hour then of course you need a well developed server. My "best performing site" that's on shared hosting gets 2000+ visits per day and is doing rather well with sub-second average page load times. The sites on the VPS I'm renting have longer average page load times and that's despite many hours gronking around with mysql variables and other nonsense that distracts me from the real purpose of running these sites.

VPS versus shared hosting

The issue that I found with VPSes and Drupal is that Drupal requires quite a bit of memory. If you have a few modules turned on (particularly i18n), a site can easily require more than 256M for Apache/PHP alone. Throw more than a few simultaneous users at the site and it will start to choke pretty quickly. I guess this will get better once you move to 1GB slices but then cost starts ramping up pretty quickly to the point where you might as well have your own dedicated server...

-Kerberos