Each day, between migrations and new projects, more and more features are becoming available for Drupal 8, the Drupal community’s latest major release. In this series, the Acquia Developer Center is profiling some prominent, useful, and interesting projects--modules, themes, distros, and more--available for Drupal 8. This week: Fast 404.
"This module is essential for big, fast, high-performance sites. The absence of a Drupal 8 version of the module was a clear gap that needed filling." Neetu Morwani
Neetu Morwani is a member of Acquia’s New Delhi team and has been working with Drupal since early 2013. During her first job, she came across Drupal and has been contributing back to the community ever since, including several mentions in core commits.
Neetu has also been mentoring people in community code sprints, delivering presentations at local meetups and was a speaker at DrupalCon Asia 2016, where her presentation was entitled Features v CMI - The battle for Drupal 8. Neetu also played a starring role in the video embedded in this post explaining why DrupalCon Asia coming to India in 2016 was so important to the country, region, and the Indian Drupal community.
Neetu upgraded the module with the support of Acquia’s Drupal 8 Module Acceleration Program.
What does the Fast 404 Module do?
404s--HTTP 404 Not Found Errors--are expensive. They cause performance and usability problems. The Fast 404 Module lets Drupal sites deal with these bad page requests quickly and efficiently, reducing the chance that 404s will cause slowdowns or crashes.
Neetu explains, “A 404 request is expensive in terms of memory because content is being requested time and time again from the server but it has either been removed, moved to another URL without proper forwarding, or an incorrect URL has been typed in. 404s don’t usually hit caching layers (because they don’t exist on the site) and this leads to disastrous effects on page load time.”
It gets worse if there are multiple 404s happening, “They can hog all the server memory. And if it runs out of server memory, it may even crash the site. It will at least cause other pages to load slowly, leading to a bad user experience.”
I asked Neetu to help me understand why this is and how the memory use can build drastically enough to crash a site. “Let's assume it takes 'X' memory to load a page and each 404 request takes 'Y' memory. A request can have 'N' number of 404s going on, because pages may have multiple assets (CSS,JS,images) associated with them and calling incorrect/nonexistent paths to these assets leads to multiple 404s. Every asset not found will lead to another 404. So this results in the request eating X+NY memory instead of just X memory. This situation lead to the development of the Fast 404 module for Drupal.”
Stop the bootstrap, save resources
The Fast 404 Module stops the Drupal bootstrapping process at level 1 (out of 8), saving resources by stopping a lot of expensive server calls from happening at all. The module has a number of configuration options, including allowing path checking, extension checking, path whitelisting, and more.
About the Drupal bootstrap process: Setting aside factors like server architectures and external caching, here’s what happens when a request causes Drupal to fully “bootstrap” and deal with the request. This also helped me understand why a 404 can be so expensive and why roughly 14,000 sites report using this module to improve their performance.
Every bootstrap step takes us a level closer to fully running site (fully bootstrapped drupal):
- DRUPAL_BOOTSTRAP_CONFIGURATION: Initializes configuration.
- DRUPAL_BOOTSTRAP_PAGE_CACHE: Tries to serve a cached page.
- DRUPAL_BOOTSTRAP_DATABASE: Initializes the database layer.
- DRUPAL_BOOTSTRAP_VARIABLES: Initializes the variable system.
- DRUPAL_BOOTSTRAP_SESSION: Initializes session handling.
- DRUPAL_BOOTSTRAP_PAGE_HEADER: Sets up the page header.
- DRUPAL_BOOTSTRAP_LANGUAGE: Finds out the language of the page.
- DRUPAL_BOOTSTRAP_FULL: Fully loads Drupal. Validates and fixes input data.
404 response using Fast 404 Module
The first image shows how 404 request responses are handled by a site with the Fast 404 module enabled. The Fast 404 module handles the request instead of “bothering” Drupal. The page output is really light, without any unnecessary assets like CSS JS, or images, and is delivered quickly.
When we inspect the markup of the response rendered by Fast 404 in the second image, we see just a few lines of markup of just few lines. Drupal is not bootstrapped; compare this markup with the full Drupal response markup below.
404 response fully bootstrapping Drupal
These two images show how a Drupal site without Fast 404 in effect. When Drupal handles a 404 request instead of the Fast 404 Module, all the assets (CSS, JS, images) are loaded, showing us that Drupal is fully bootstrapped (to level 8).
Looking at the markup gives you an idea just how much code is generated as the result of the full Drupal bootstrap, which has happened in this case.
Faster, more reliable sites
Neetu goes through the potential consequences, “A 404 request, any 404 request can consume a lot of resources on the server. This increased server load leaves less resources--including bandwidth--available for other legitimate requests. If there are too many 404s on the site, through pages being (re)moved and the site not being updated properly, or through paths to other on-page assets changing, it can lead to poor site performance or even crash the server.”
“As developers, our top priority is to deliver great user experiences. Those, in turn, should result in increased revenue and market reputation. Not taking care of 404 requests may lead to bad user experiences that drive visitors away from our sites. You don’t want this, no matter what your site is, but the direct loss of business can be especially painful if you’re running an eCommerce site, for example.”
When was the Fast 404 module created?
The Fast 404 Module was originally written by Michael Cooper (soyarma) at Acquia in 2011. A client request brought the module to the attention of the Acquia Module Acceleration Program and Neetu began working on the Drupal 8 port in April 2016.
“This module is essential for big, fast, high performance sites. The absence of a Drupal 8 version of the module was a clear gap that needed filling. I’d like to thank Adam Balsam and Abhishek Anand for giving me the opportunity to work on this nice porting project,” Neetu concludes.
Has Drupal 8 changed this module?
“There is no change in 8.x version of the module in terms of functionality. But we were able to take advantage of the architectural changes in Drupal 8 in our rewrite. The upgrade was interesting and a great learning experience for me as a developer because of the differences between Drupal 7 and Drupal 8.” Some of the points Neetu mentioned were:
- D8 is all OOPs based whereas D7 is procedural based programming.
- The concept of event subscribers in D8--derived from the Symfony framework--helped us a lot here and is pretty much the main essence of the module.
- Major learning - In depth knowledge of events (Check out the api.drupal.org reference on events in Drupal 8!)
- What are events?
- How events in Symfony and Drupal 8 work.
- What is the EventDispatcher and how are events dispatched?
- Benefits of using events.