CHAPTER 23 ■ OPTIMIZING DRUPAL

<FilesMatch "\.(png|gif|jpe?g|s?html?|css|js|cgi|ico|swf|flv|dll)$"> ErrorDocument 404 default

</FilesMatch>

Disabling Modules You’re Not Using

Disable any modules that you are not using to avoid Drupal interacting with these modules. Don't leave devel modules running on your production site!

Drupal-Specific Optimizations

While most optimizations to Drupal are done within other layers of the software stack, there are a few buttons and levers within Drupal itself that yield significant performance gains.

Page Caching

Sometimes it’s the easy things that are overlooked, which is why they’re worth mentioning again. Drupal has a built-in way to reduce the load on the database by storing and sending compressed cached pages requested by anonymous users. By enabling the cache, you are effectively reducing pages to a single database query rather than the many queries that might have been executed otherwise. Drupal caching is disabled by default and can be configured at Configuration -> Performance. For more information, see Chapter 16.

Bandwidth Optimization

There is another performance optimization on the Configuration -> Performance page to reduce the number of requests made to the server. By enabling the “Aggregate and compress CSS files into one” feature, Drupal takes the CSS files created by modules, compresses them, and rolls them into a single file inside a css directory in your “File system path.” The “Aggregate JavaScript files into one file” feature concatenates multiple JavaScript files into one and places that file inside a js directory in your “File system path.” This reduces the number of HTTP requests per page and the overall size of the downloaded page.

Pruning the Sessions Table

Drupal stores user sessions in its database rather than in files (see Chapter 17). This makes Drupal easier to set up across multiple machines, but it also adds overhead to the database for managing each user’s session information. If a site is getting tens of thousands of visitors a day, it’s easy to see how quickly this table can become very large.

PHP gives you control over how often it should prune old session entries. Drupal has exposed this configuration in its settings.php file.

ini_set('session.gc_maxlifetime', 200000); // 55 hours (in seconds)

514

CHAPTER 23 ■ OPTIMIZING DRUPAL

The default setting for the garbage collection system to run is a little over two days. This means that if a user doesn’t log in for two days, his or her session will be removed. If your sessions table is growing unwieldy, you’ll want to increase the frequency of PHP’s session garbage collection.

ini_set('session.gc_maxlifetime',	86400); // 24 hours (in seconds)
ini_set('session.cache_expire',	1440); // 24 hours (in minutes)

When adjusting session.gc_maxlifetime, it also makes sense to use the same value for session.cache_expire, which controls the time to live for cached session pages. Note that the session.cache_expire value is in minutes.

Managing the Traffic of Authenticated Users

Since Drupal can serve cached pages to anonymous users, and anonymous users don’t normally require the interactive components of Drupal, you may want to reduce the length of time users stay logged in or, crazier yet, log them out after they close their browser windows. This is done by adjusting the cookie lifetime within the settings.php file. In the following line, we change the value to 24 hours:

ini_set('session.cookie_lifetime', 86400); // 24 hours (in seconds)

And here we log users out when they close the browser:

ini_set('session.cookie_lifetime', 0); // When they close the browser.

The default value in settings.php (2,000,000 seconds) allows a user to stay logged in for just over three weeks (provided session garbage collection hasn’t removed their session row from the sessions database).

Logging to the Database

Drupal ships with the Database logging module enabled by default. Entries can be viewed at Reports -> Recent log entries. The watchdog table in the database, which contains the entries, can bloat fairly quickly if it isn’t regularly pruned. If you find that the size of the watchdog table is slowing your site down, you can keep it lean and mean by adjusting the settings found at Configuration -> Logging and errors. Note that changes to this setting will take effect when cron runs the next time. Not running cron regularly will allow the watchdog table to grow endlessly, causing significant overhead.

Logging to Syslog

The syslog module, which ships with Drupal core but is disabled by default, writes calls to watchdog() to the operating system log using PHP’s syslog() function. This approach eliminates the database inserts required by the Database logging module.

Running cron

Even though it’s step nine of Drupal’s installation instructions, setting up cron is often overlooked, and this oversight can bring a site to its knees. By not running cron on a Drupal site, the database fills up with

515