Independent Cache (with delayed removal)
Categories
Component ID
Component name
Component type
Maintenance status
Development status
Component security advisory coverage
Component created
Component changed
Component body
What is?
A delayed to clear cache.
An implementation of a cache to be used selectively on Views and Blocks so that they don't get cleared when a Drupal Clear cache is issued or other triggers that would other wise immediate clear the cache and cause a regeneration of the data/content.
The concept behind this cache is that by choosing which views and/or blocks are too heavy to generate (causing the server performance to go down on high traffic sites), allowing them to be generated some time after and not at the same time, doing a redistribution of the work during time.
Why?
At some events the cache is cleared and therefore all data needs to be generated and processed again, if this happens for some heavy processes on a high traffic site you may end up running several heavy process at the same time plus all the small process and you may bring the server down temporary, similar to what happens with a DOS attack.
If we can delay the most heavy parts to be processed after all other caches are ready and meanwhile we use "old" caches for those parts until we get those processed again it would allow to redistribute the processing during time and not all at the same time.
How?
Independent: By using a file cache (yes, in some circumstances file cache can incredible great) we create independency, so that if externally memcache or other system gets cleared this cache will remain.
Delayed: We would mark those caches that will need to be generated later and will also have definition of maximum times, so that they get removed by a garbage collector later and by pieces, not at the same time.
Cons
This is NOT for every project, this is not a one size fits all project.
This is not even planned to be used as the complete cache for everything in the site.
Having some parts not cleared when all the rest do may cause some problems, for example if you use a reverse proxy or page cache you may at some times get stick with parts of your pages old for long time, not saying they can't be used together, but if you use them together you may need to revise the other more general cache's life time so that eventually these too get updated.
Right now I have one implementation on a production site working together with Cache Router module and I'm working to make it independent and make some improvements.
I'll be posting a first version soon, but if you are interested contact me and I may rush it for you.
