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
- Background Process for graceful caching
- Drupal Queue for graceful caching via queued requests
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
- Module categories: Performance
- Created by gielfeldt on , updated