Experimental project

This is a sandbox project, which contains experimental code for developer use only.

Static page caching with asynchronous "ESI" capabilities and graceful recaching. This is more of an academic exercise and a hobby project than anything else. It's not an attempt to compete with other caching modules, like Boost.

Goals

  • Work out of the box for any Drupal installation
  • Scalability through graceful recaching either by queueing requests or background processing
  • Extra performance through page_cache_fastpath() and mod_rewrite rules
  • Prevent thundering herds
  • Supply self-contained cache invalidation without having to rely on a cron job handling this

Requirements

Caveat

If using NFS for storing cache files, this will only work with NFS v3, as file locking is used.

Performance

Preliminary synthetic benchmarks using "ab -n1000 -c1" on the frontpage (D6):

Caching Requests/sec. Requests/sec. (xcache)
None 12.85 37.41
Drupal normal page cache 128.05 285.33
Drupal Aggresive page cache 146.99 385.49
HTTP Accelerator out-of-the-box 93.02 282.26
HTTP Accelerator page_cache_fastpath() 141.51 439.37
HTTP Accelerator mod_rewrite 1852.91
Boost 1457.88 -
Varnish 6567.67 -

As you can see Drupals aggressive page is actually faster in some cases. However, the goal of HTTP Accelerator is not to be faster as such, but to just "do it better" in terms of concurrency and cache-invalidation.

Boost seems to be slower, but I believe the extra overhead for Boost lies in the mod_rewrite rules which are a bit more elaborate and has more features.

Since HTTP Accelerator somewhat acts like a reverse proxy cache, it is inherentely more "aggressive" than Drupals aggressive page cache.

Of course HTTP Accelerator will be vastly out performed by true HTTP accelerators, such as Varnish. HTTP Accelerator is merely a technology exploration project for encapsulating these caching mechanisms entirely within Drupal. Perhaps HTTP Accelerator could be usable for shared hosting when it's finished.

Also with asynchonous "ESI" and graceful recaching, better cache separation of objects could result in an overall better performance than other Drupal only solutions (even load, without spikes, etc.) .

Project information