This project is not covered by Drupal’s security advisory policy.

Test Plan 01 - Comparison of Standard Drupal Cache and Magic Cache on application with around 133 active modules

Experimental cache module for Drupal core modules, which work for anonymous and logged users as well.
It will increase your performance even 2x on very heavy websites, when other caches are useless.
It's not a standard cache engine, so you can mix it with other cache engines as well.
No need to change your settings.php file.


It's not ready for production servers yet.
Requirements to see some improvements: probably around more than 100 activated modules
Please use it only for testing purposes.
See some benchmarking statistics here:
#471322: Initial test


Probably you need at least more than 100 activated modules.
Nobody using cache engine, if website is loading fast.
If you have problem with performance, then install this module.
Please use it for testing purposes, because it could cause some side effects.
Later it should become more stable.


- Just enable the module;)


This module changing system and menu_router core tables to run cache engine and it's not stable yet, so in case when your experience WSOD - please execute WSOD from DTools module (emergency mode) to fix common WSOD issues.
If you are not experienced user, please do not install this module to prevent any damage of your website.


Currently there are 3 caching methods available:

All available functions (handled by cache engine) are are declared, but body of functions are created on the fly when it's called (eval). In this case hundred of .module files are not physically loading from your disc each page refreshment.
Difference between this method and eval is that, when you've got active hundreds of modules which are loaded file by file each refreshment (include_one), then even the content of all functions takes a lot of time to load them in one time (even from memory).
Probably it's the best method.

It's very similar to dynamic method, but all code of all activated modules are loaded to memory. Application will spend less time making include_one call to hundreds of files and interpreting each file separately per each refreshment.

all core modules are loaded from separately files with cache callbacks
it's a little bit slower than eval, but it's good for diagnostics purposes


Currently there are 4 caching storage methods:

On init cached data is prefetch once from cache db into globals.
On shutdown, changes in cached data is saved into cache db.
Each user and each menu_router callback have their own cache data.

Cache storage is disabled.
Used for statistics, diagnostics and handling core hooks.


Reviews and additional statistics are welcome.

Project Information