Date de publication: le Mercredi 8 Avril 2009 à 19h54
Dernière modification: par Pascal BOYER le Jeudi 30 Avril 2009 à 19h58

30/03/2009 11:19

Avec l'aimable et profitable relecture de l'auteur: Nicolas Pastorino

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.
Cet article décrit dans le détail les principes et fonctions du nouveau système de cache présent dans eZ Publish 4.1. Globalement, l'idée peut se résumer à ceci: au lieu de supprimer les éléments cachés (présents dans le cache) pour les régénérer par le biais de requêtes concurrentes, la logique est inversée par un algorithme de rafraîchissement. Concrètement, un élément caché sera marqué comme étant invalide et ne sera supprimé que lorsque la nouvelle version cachée existera. Pendant toute la phase de génération de cette nouvelle version et jusqu'à ce que celle-ci soit efficiente, c'est l'ancienne version cachée qui est servie aux internautes.

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.
Cette amélioration découle des précieux retours d'informations que nous obtenons. Les utilisateurs de eZ Publish frappent souvent à notre porte pour nous parler de leurs problèmes de performance lorsque de nombreux rédacteurs s'(hyper)activent sur leur application basée sur eZ Publish.

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 ).
Pour ceux qui ne connaissent pas les détails du problème, revenons sur certaines informations de base pour comprendre la problématique à laquelle font face ces utilisateurs. Lorsque, par exemple, est affiché un objet, disons en mode vue full, eZ Publish stocke le résultat HTML du traitement du template (il le met en cache). Cet élément mis en cache est appelé Cache de vue et sera réutilisé la prochaine fois que ce contenu sera affiché par le même moyen. Cette technique évite de réaliser le traitement des templates d'affichage chaque fois qu'un objet de contenu est affiché, allégeant significativement la charge de l'application. Ce système existe maintenant depuis longtemps (un peu avant la version 3.0 de eZ Publish).

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.
Pour que le contenu affiché soit pleinement synchronisé avec le vrai contenu, c'est à dire synchronisé en temps réel autant que possible, le cache de vue d'un objet de contenu expire chaque fois qu'une nouvelle version de l'objet est publiée. Cela signifie que le code HTML caché doit être régénéré, impliquant que le template d'affichage soit à nouveau traité lorsque la nouvelle version de l'objet de contenu est affichée pour la première fois. Vous trouverez plus d'informations dans l'article Système de cache des vues.

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.
Le cache de vue est pris en exemple ici, mais les améliorations apportées par la fonctionnalité Stale Cache s'appliquent également aux caches de blocs et à tout autre type de cache. Retenez également que cette fonctionnalité s'applique tant aux environnements clusterisés qu'à ceux qui ne le sont pas.

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 :
Lorsque plusieurs utilisateurs demandent le même objet dont le cache de vue vient d'expirer, leurs requêtes sont placées en file d'attente, la première d'entre elles étant la seule à déclencher la régénération du cache de vue. Cela implique que presque toutes les requêtes (exceptée la première) reçues à ce moment précis devront attendre que la nouvelle version cachée soit disponible, entraînant deux inconvénients majeurs:

• 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.
  Expérience utilisateur: les clients attendent au moins le temps nécessaire à la régénération du cache, ce qui peut être long lorsque des templates complexes sont utilisés.
• System level : all these queued requests put a lot of pressure on the system's resources ( race conditions, deadlocks, ... )
  Au niveau du système: toutes ces requêtes en attente mettent la pression sur les ressources du système (situations de compétition, interblocages (deadlocks), etc...).

Commentaires