Fast 404

What and Why

Drupal has expensive 404 errors. On an 'average' site with an 'average' module load, you can be looking at 60-100MB of memory being consumed on your server to deliver a 404. Consider a page with a bad .gif link and a missing .css file. That page will generate 2 404s along with the actual load of the page. You are most likely looking at 180MB of memory to server that page rather than the 60MB it should take.

That's where Fast 404 comes in. This module combines a very common method of handling missing image/file 404 errors (discussed here and planned for Drupal 8) with a method created by dpardo (a co-maintainer of this project) to deliver super fast 404 error pages for both missing images and bad paths. Depending on which method of implementation you choose (aggressive or super aggressive) you can deliver 404 errors using less than 1MB of memory on your server.

Drupal 7 Core Updates

Drupal 7 core has updated to add a rudimentary version of what this module implements. It allows you to set an excluded set of paths, a list of extensions to Fast 404 on, as well as the plain HTML that is delivered.

Issue describing: http://drupal.org/node/76824
Patch added: http://drupal.org/files/issues/404_fast_paths_7x-76824-328.patch
New function: http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/drupal...

Below is a matrix of the difference between this module and the new D7 functionality.

Installation and Settings

Fast 404 requires some configuration in the settings.php, and the readme.txt file contains a full set of options to enter in your settings.php. The default settings only check for missing files by looking at extensions. This occurs during Drupal boostrap, around step 7 using hook_boot.

If you do not install the module in /sites/all/modules, then you will need to change the include line in the settings.php.

White Listing

If you want to be very aggressive with checking for bad paths by extension/filename, you can turn on whitelisting. Unlike regular extension checking which looks for a specific set of extensions to see if the missing file matches them, whitelisting sets a fixed list of valid file names and only allows those to pass to the drupal bootstrap. This is somewhat more dangerous as you will need to know if any modules you run generate aliases ending in .xml, or if any modules use their own php files which then bootstrap drupal.

Whitelisting is one of the fastest methods of path checking against urls with file extensions, but requires you to know all paths your site uses.

Path Checking

you can change the 'fast_404_path_check' to TRUE, which will also check paths that do not have extensions on them (like: content/my-content-name). While this has been tested with several sites and setups, it is not been through enough sites for us to be certain it is foolproof. Be sure to browse your site and check for inadvertent 404 errors. Let us know if you find any false negatives and we will endeavor to improve the module.

Aggressive Extension Checking

This can be used with whitelisting on or off. If used with whitelisting, then its super fast, without its just damn fast. To use this, uncomment the 'fast_404_ext_check();' function that is placed in settings.php from the readme.txt code. This will then check extensions at bootstrap phase 3 rather than 7.

Aggressive Path Checking

Like Aggressive extension checking, this does the path check from within the settings.php and at boostrap phase 3. This is somewhat experimental is it reads the database connection information out of settings.php and connects to the DB before Drupal does. In most MySQL/PHP setups/configs Drupal will re-use this database connection, but it is possible that it will not.

If you hardly have any 404s then this may not be desirable as it adds extra work to each page load. However, if you have a lot of 404s and saving hundreds of MB of system memory each second is worth the added 1MB load to your legitimate pages, then this is a great setting for you.

Note: It only works with MySQL and MySQLi and only with single DB setups. If the module detects that your $db_url variable is actually an array, then then check will not occur from within settings.php and will wait until drupal gets to hook_boot.

Thanks!

Special thanks to the folks in Drupal thread http://drupal.org/node/76824 for all their fine tuning on the extension checking which I ripped off wholesale, and to dpardo, whose idea it was to do path checking in addition to extension checking.

Be prepared to have your server shout for joy as massive memory and CPU load comes off and it is able to focus on real pages for users.

Module Status

The module is in a very stable place, though we are doing performance enhancements to the path checking. Also we're adding compatibility with the D7 drupal_fast_404 checking. The 7.x-1.x branch contains the latest code and is where development should occur.

Both D6 and D7 versions are considered stable.