Did you know that a 404 could cripple your website? We'll believe it or not misconfigured or ignored 404s could be killing your websites performance. Let's see how.
First things first, what do 404s look like in Drupal 7 out of the box? If you view the headers of a 404 page you will see the follow:
Cache-Control:no-cache, must-revalidate, post-check=0, pre-check=0
This header basically tells all caches onward not to cache the page. If this is the case then what you have is a potential hole for DDoS yourself. We can say this because not only does it bypass cache but a full Drupal bootstrap then depending then on what your 404 page is, you could have any number of blocks/panes/views loading all of which could be expensive to generate. If there were a flurry of 404 in quick succession then you might be in trouble. So it is really important to trace through your application for the case of a 404.
So the clever people in the Drupal community identified this was a big deal and initially rolled out a simply fast_404 check in core and then developed the fast_404 module. As the project page states this aims to return a 404 errors using less than 1MB of memory on your server, also allowing for some pretty advanced and comprehensive configurations.
Drupal 7 core includes a basic fast_404 check early in the bootstrap process which can be enabled by uncommenting the line drupal_fast_404(); in the default settings.php. In this case Drupal checks the path prior to bootstrapping the database, leading to faster page returns for most 404 responses as well as a lessening of the overall memory usage of the site.
In summary its worthwhile checking your apache logs regularly to keep a track of 404s hitting your website so either you can fix broken links or add redirects as needed. The other piece is to check how your site performs when a 404 is requested, you wont regret double checking. If you are using a cache upstream, it would be worthwhile also adding a short TTL so these will be caught and protect your back ends.