Performance

This module integrates Node.js with Drupal.

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

D7 alt: https://www.drupal.org/project/views_random

This project enhances the back end performance of core's CSS and JavaScript aggregation features.

7.x

Features (7.x)

Important disclamer

While this was a nice PoC from my point of view, I never maintained this module. Please use mature solutions instead such as https://github.com/makinacorpus/drupal-gulpifier or https://www.drupal.org/project/advagg instead.

Original module summary

THIS MODULE IS NOT DRUPAL CORE: it provides some CSS and JS file handling replacement FOR core. Please stop filing issues for core bugs in here.

This module changes the Drupal core aggregation mecanism process. It greatly reduces I/O and aggregated number of files, and improves chances of client cache hit, therefore while it produces bigger aggregated files, it reduces greatly the bandwidth utilization while users browse.

This is achieved by bypassing the dynamic CSS and JS inclusion. Instead of including and aggregating only needed files on a per-page basis, it learns files being used site-wide while user browse, then is able to produce larger therefore more revelant files that aggregate all those atomic files whether or not they are being used on the page.

Over time, the number of aggregated files reduce to achieve a stable state where all site JS files are being aggregated in one file only, and all site CSS are being aggretated in only two files (libraries into one side, theme files into another, can be more if there are browser-specific files).