Monday 30 March 2009 2:19:00 am
Instead of letting these queued clients wait until the new version of the cache is ready ( and stress the servers ), why wouldn't we show them the former version of the cache ? This case would not happen very often, and who would be the most unsatisfied client : the one waiting 20s for a page to be displayed, or the one seeing a former version version of it once or twice, and the updated version a few seconds later ? Well, that is a trade-off between user experience and content freshness, and going for the solution where user experience is maximised, and content freshness gracefully degraded, sounded like the way to go.
That is what “Stale Cache” is all about. It brings a much smarter cache-handling, significantly improving the overall performance of a website, both being user-centric and system-friendly.
Let's dig into the implementation details of Stale Cache....WARNING : Jargon alert :)
Below is presented the state machine of the Stale Cache feature. As “an image is worth thousand words”, we made this diagram as self-explanatory as possible.
Note that this behaviour is natively embedded in the eZDB cluster file handler, meaning that any clustered eZ Publish instance directly benefits from Stale Cache. However, due to a PHP limitation on Windows, concerning the touch() function ( http://www.php.net/touch ), Stale Cache is not enabled by default on the non-clustered eZ Publish instances. If you are not running Windows, or if you upgraded to PHP 5.3 at least and are running Windows, it is strongly recommended to enable Stale Cache. It is shipped in an alternative to the eZFS file handler, called eZFS2, which can be enabled through the following process :
<?php/* #?ini charset="utf-8"? [ClusteringSettings] FileHandler=eZFS2FileHandler */ ?>
Clear caches, and there you go...check the ' Results' section if you still are not convinced !