Bertrand Dunogier

Since eZ publish 4.1 has finally been released today, I’m gonna take advantage of this opportunity to expose some real life benefits of one of the major, even though low level, new features in this release.To quote the official announcement:

Improved cache mechanism & performance enhancementsImportant enhancements include changes to the cache system for high traffic sites and related optimizations. The basic idea implemented is that caches are not deleted and then regenerated, but new versions are made by the first request needing them, while other request are receiving the expired cache elements until the refresh is complete. This basically avoids mutexes and DB deadlocks for high traffic sites.

Yesterday, while on eZ publish support duty, I had a chance to compare the difference between a database cluster with and without stalecache. Our customer was benchmarking a website with 20 concurrent users, clearing ALL cache in the middle of the process, with quite complex templates. Without stalecache processing, the database was almost dying: dozens of identical queries were being processed by MySQL, all mutually exclusive, resulting in a total absence of response from the website. This was going on for several minutes.After a small backport work of the stalecache features from 4.1 to 4.0, the result was actually better than expected: I couldn’t see ANY of the insert queries. The website was still perfectly responsive while the cache items were being generated. The feature simply allowed us to move from a dead server to a perfectly usable website.We’ll try to provide some more numbers about this, but I have a very, very clear feeling that this change is a major step forward toward high-availability & performance eZ publish setup.