404 Expenses Not Found !!

Everyone out there on web must have come across "404", "Page Not Found" messages. The

most important thing with these 404s is that they will happen, they are inevitable.

Before moving into complexities, lets recollect what a 404 error means.

In simple words, 404 is that our server is not able to find what we have requested, so it says

“Sorry buddy, I give up." in the form of page-not-found messages.

Keeping in mind this inevitability of these 404s, you can wonder what problems it can pose to our

site and what these 404 errors can cost us.

Imagine a website, trying to fetch dynamic resources for each of it's page request, some of which

may result in a 404. Such requests, resulting in a 404 on a heavy traffic site can eventually add up

to be actually troublesome.

Hold on ... there is more to it.

Let's see what happens when Drupal comes into picture.

Even while serving a 404 page in Drupal, it does the full "bootstrap", loading all settings, modules,

connecting database etc. Drupal consumes a lot of memory to serve a request which is at times

404 and with the increase in number of such requests the amount of resources spent on them

also climbs up the ladder. So, a situation of continuous 404 dynamic page requests can end up

screwing our server.

Ohh ... 404s are expensive.

But once again thanks to Drupal community for providing us the magic wand in our hand :)

And this time, it's the Fast 404 module.

This provides cheaper 404s ... rather cheapest i guess ;p

So why not lets go ahead and give it a try.

Before going into the details of the module, let's have a quick overview of how Drupal's core

serves fast 404 pages.

In Drupal's core with Fast 404 pages enabled, after bootstrapping it tries to deliver the page and

checks if the requested page is available or not. If not, Drupal calls the function drupal_fast_404()

to return a fast 404 page which means Drupal is looking for a path without any menu callback

associated, thus bypassing normal Drupal page rendering.
Also we can call this function as soon as settings.php is loaded to prevent a Drupal bootstrap on

these pages.

Apart from speeding up the server response time, this also prevents the 404 error from being

logged in the Drupal system log. Well, everything comes at the cost of something, right ?

Calling the function from settings.php has some disadvantages like it can interfere with the

functioning of dynamically generated files, can break Drupal's ImageCache mechanism that

depends on the 404 handling to auto-generate versions of files that doesn't exist. For further

clarifications please refer to this.

So, here enters the module Fast 404 :

How does Fast 404 serves 404 requests ?

Good question, lets find out where the actual magic lies.

What actually is the cause of 404s being so expensive ?

Yes, its the bootstrap phases which cost us this overhead.

Fast 404 doesn't fully bootstrap on 404's for certain file types if it's enabled and returns a simple

404 Not Found Page, checking for it on boot by implementing hook_boot(). The basic installation

of Fast 404 only checks for static files and not Drupal paths.

Not bad at all, now we have a mechanism to handle missing static files without investing a lot on

them.

But is this still not enough, do we need to save even more ?

Go ahead and choose to return an even less expensive Fast 404 page for missing pages from

settings.php which is faster way as it checks for missing static files at bootstrap stage 3 rather

than 7 when the module's hook_boot() is called.

In order to do this follow the instructions of README.TXT of Fast 404 module.

Adding to this, we can also enable Drupal path checking from here to ensure whether the

requested path is actually an existing Drupal page or not

or else we can directly call the function fast_404_path_check(); from settings.php itself.

Well, no doubt the path checking done in settings.php will give us an earlier knowledge of the

current requested path to be 404 or not. That's good ... but wait ... how does this

fast_404_path_check() gets to know whether it's a default function call or a call from settings.php

and how does this function checks for paths at such an early stage of bootstrapping even when

we do not have database functions loaded yet. Curious to know ??
Let's check out the function.

function fast_404_path_check() {
  .
  .
  .
  // Determine if we have the db_query function. If so, we are in boot and
  // have functions. If not we are in settings.php and do not have functions.
  if (function_exists('db_query')) {
    (Check to see if a path works using Drupal MySQL functions)
    $valid = fast_404_validate_path_drupal();
  }
  else {
    (Check to see if a path exists using plain MySQL functions)
    $valid = fast_404_validate_path_mysql();
  }
  .
  .
  .
}

To be frank, actually this was one of the points which was actually forcing me to scratch my head

when I first came to know that we can do path checking at such an early stage of bootstrap.
Fast 404 takes care of imagecache URL and leaves it to be handled by Drupal, thus avoiding any

interference with the dynamically created files.

This also provides few more variables that can be set to make this fast 404 mechanism even

more versatile. URL white listing is one such functionality of Fast 404. For further details please

refer the documentation of the module.

And that was all about the magic of Fast 404.

So move on, create your custom static 404 page (try this), feed the Fast 404 module with your

creation (set the variable $conf['fast_404_HTML_error_page'] with the path of your custom 404

page) and then CHILL!!

Let users hit your site with whatever they can ... 404s are NO MORE EXPENSIVE :)

(To all newbies in Drupal, Friends! Today I went back to the initial level of Drupal page serving

mechanism i.e bootstrap to get a better picture of it which I was actually missing even after being

with Drupal for few months. So we should never hesitate to turn back the pages if you are stuck

anywhere. CHEERS TO LEARNING!!)