eZ Publish Knowledge Series: «Stale Cache» or «How caches in eZ Publish 4.1 are handled in a smarter way»

This article describes in detail the principles and functions of the new cache system present in eZ Publish 4.1. Overall the idea can be summarised as follows: instead of deleting cache elements and then regenerate them across concurrent requests, the logic is reversed to a refresh algorithm. Basically a cache element will be marked as invalid but not deleted until a new version is ready. During the generation of the new cache element, the old version will still be served until it is ready.

This enhancement stems from valuable feedback we got from the market. Many times, adopters of eZ Publish knocked on our door to tell us they had performance issues when lots of content editors were (hyper)active on their eZ Publish-based application.

Introduction

For those who are not familiar with the details, let's brush up on the background information required to understand the problematic they stumbled upon. As an example, when displaying a content object, say in 'full' view mode, eZ Publish stores the HTML resulting from template processing ( or “caches it” ). That is called the “View Cache”, which will be re-used next time the piece of content is displayed the same way. This prevents from processing the display templates every time the content object is displayed, significantly alleviating load on the application. This system has been in place for a long time now ( slightly before 3.0 ).

In order for the displayed content to be in full sync with the actual content as real-time as possible, the View Cache for a content object is expired when a new version of the object is published. That means that the “cached” HTML needs to be refreshed, causing the display template to be processed anew the first time the content object is displayed in its new version. More information can be found here: http://ez.no/doc/ez_publish/technical_manual/4_0/features/view_caching.

The “View Cache” is taken as an example here, but improvements brought by the Stale Cache feature also apply to Cache Blocks and other types of cache. And please also note that this feature applies to non-cluster modes as well as cluster modes.

When several concurrent users are requesting the same object, for which the View Cache just expired, requests are queued, only the first of them triggering the View Cache regeneration. This implies that nearly all requests received at this specific moment ( except the very first one ) will be waiting for the fresh cache to be available, raising two major drawbacks :

• User experience level : clients are waiting at least the time needed to recreate a piece of cache, which can take a long time when complex templates are in use.
• System level : all these queued requests put a lot of pressure on the system's resources ( race conditions, deadlocks, ... )