Clustering in eZ publish 3.8

eZ publish versions prior to 3.8 could also be run in a clustered environment. However, these configurations were subject to occasional race conditions when files were updated or removed. Since all cache files and images were stored locally on the hard disk of each web server, files needed to be synchronized between each server. This was the source of the problems in prior eZ publish versions.

Cache file coherence

The most common issue was that eZ publish cache files were not coherent. One scenario that illustrates this is shown in the diagram below. In this two-server configuration, each server has stored its own eZ publish cache locally on the hard drive. The cache is stored "on-demand", with cache files created as pages are requested, so in this scenario Server 1 has three cache files and Server 2 has two cache files. The different files can contain different view modes or permissions for the same piece of content.

When a user updates some content, the cache for the content is cleared. However, the cache needs to be cleared on both servers. So, in this scenario, we clear the same files (File A and File B) on both servers. However, Server 1 has cache File C which has not been cleared. This means that the cache is wrong and served pages may contain the wrong content.

Failed synchronization of cache File C.

Cache hit ratio

The "hit ratio" is the percentage of all access requests that are satisfied by the data in the cache. Since cache files were generated on-demand on each server, the hit ratio was lower than it could be, meaning that the cache was not fully effective. Each server in the cluster must generate a cache for any given page. Therefore, the more servers that were added (thus distributing page requests), the less frequently they were serving cached content (because the cache files were distributed across multiple servers).

Image synchronization lag

Another problem occurred when images (or any kind of binary file) were uploaded to eZ publish. Images were stored locally on the server to which they were uploaded. However, other page content was stored in the database. Since multiple servers use the same database, the database content was instantly available to each server but the image file was not.

The time to transfer the image from one server to another varied according to the configuration, but, with rsync and cron jobs, the synchronization could only be triggered every second. This caused a potential lag. During this lag, if a request was served that included the updated content, eZ publish looked for the image on the local hard drive. Because the image couldn't be found, eZ publish was unable to create a variation or generate the image path. (This could also result in a cache file with a broken image reference.)

As a result, sometimes images were not displayed. The diagram below illustrates this scenario.

Delayed synchronization of images.