CHAPTER 23 ■ OPTIMIZING DRUPAL

The current query cache size can be viewed as output of MySQL’s SHOW VARIABLES command:

mysql>SHOW VARIABLES LIKE 'query_cache%';

Experimenting with the size of the query cache is usually necessary. Too small a cache means cached queries will be invalidated too often. Too large a cache means a cache search may take a relatively long time; also, the RAM used for the cache may be better used for other things, like more web server processes, memcache, or the operating system’s file cache.

■ Tip In Drupal, visit Reports -> Status report and click the MySQL version number to get a quick overview of the values of some of the more important MySQL variables. You can also check if the query cache is enabled from that page.

MySQL InnoDB Performance on Windows

MySQL’s InnoDB storage engine, which is Drupal’s default choice when using MySQl, has especially slow write performance on Windows. This poor performance will surface in Drupal if you try load the Admin Modules page and notice you have time to go make a sandwich. You have two ways of fixing this: either convert all tables to MyISAM (OK choice for servers with light traffic), or in your MySQL config set innodb_flush_log_at_trx_commit=2, which tells InnoDB to be less zealous about waiting for disk writes to complete.

Drupal Performance

There are two often overlooked areas for improving Drupal performance that are simple to implement.

Eliminating 404 Errors

One of the most overlooked performance drains of a typical Drupal site are seemingly innocent 404 (File not found) errors. This is because Drupal is often configured to deliver a full dynamic response to a 404 error, even if that request was for a tiny image file in a forgotten style sheet or a favicon.ico deleted long ago.

The solution is to resolve each of the 404 errors reported in Drupal’s admin logs, and change the ErrorDocument directive in your .htaccess to look something like this:

513