My Drupal site is slow! What can I do? - Part 2

My Drupal site is slow! What can I do? - Part 2
I’ve already covered some issues that you need to be aware of when hosting a Drupal project, in the previous article, My Drupal site is slow! What can I do? – Part 1. In this part, I’ll talk about a few ways you can help cure some of your performance problems without needing lots of low-level administration knowledge.
Firstly, the Devel module is your friend. Devel can help you find out where the prime offenders are in terms of any slow queries. Turn on the query logging in the settings page and check your query times and number of queries.
If you have lots of queries on certain pages, there are a few options you can consider, depending on your user base. If you have certain queries which are constantly slow, you need to consider your options:
is there another way of getting the same information? For example, could you write a custom coded query in the block/node/panel etc, instead of using a complicated view?
do you really need that module? Some modules are added for the sake of it, to add “flair” to a site, but not all of these are expertly written, or may have problems with scalability
can you implement some sort of full or partial caching mechanism? On shared hosts, high contention over resources will be a likely cause of problems – flat file serving can help here.
If you have mostly anonymous users hitting your front page (assuming this is the real “problem” page), then this isn’t so bad; Drupal has a built-in caching system, which can help. This does involve using the Drupal bootstrap process though, and still involves database access, so if the bottleneck is between your database and web servers, this might not be enough.
If you want to really speed things up for anonymous users, then you can consider a module such as Boost (another is fastpath_fscache); these provide static page caching in the file system, which negates the need for DB access and also Drupal bootstrapping – your web server can serve flat files directly. This is not so useful if you have a lot of logged-in users, as the cache will become quickly dated via this method of working. This could help you through a “slashdotting” though…
Boost comes with quite a lot of documentation (somewhat rare on some Drupal modules), but does require knowledge of the workings of htaccess. Boost also has a well looked after issue queue (last update: less than one day, at time of checking).
Another module worth considering is Block Cache, which as the name suggests caches blocks(!) – useful if you are using a lot of these on one page, perhaps in a complex Panels setup, for example. This is a worthy addition, as it works for authenticated users, so you can have a two-tiered caching system; all pages cached for anonymous users (presumably cache refreshed at intervals by cron) and blocks only cached for authenticated users. This functionality is now a part of Drupal 6 core.
If you’re suffering from database query nightmares, perhaps you could take a look at the QueryCache module. This caches queries to the database, so again this would be useful on sites where there are lots of authenticated users.
If you’re looking to get really technical about the whole matter (ahem!) then you can look to the MemCache module, which forces cache tables to be stored in memory. This has a few dependencies though, and requires “proper” system administration privileges and experience.
This is just a brief overview of some solutions to bottlenecks in your Drupal installations. There are of course a large number of variables in any setup, so you really need to have a clear plan of attack up front! Here are some more resources which cover these areas in greater detail:
http://2bits.com/articles/tips-on-speeding-up-your-drupal-sites.html
http://codesorcery.net/2007/07/23/boost-your-drupal-site/
Posted by Nik - October 10th, 2007 at 6:45pm