Comprendre le fonctionnement bas-niveau du cache eZ Publish : Le cache de INI (Article 1)

• Publié le 04 mars 2012
• 2 commentaire(s)
• Catégorie : Technologies Web

eZ Publish est un CMS infiniment flexible et puissant, qui propulse actuelle une grande variété de sites à faible ou à fort trafic. Cette puissance a un prix : la consommation de ressource en général, et la consommation de ressource SQL en particulier, ainsi que les I/O disque !

Autant de mécanismes à maîtriser pour dimensionner son architecture, ou comprendre l'impact d'un paramètre, d'une directive de cache-block ou encore d'une suppression massive de cache (template, cache-block ou cache de vue).

“

La lecture de ce tutoriel est particulièrement pénible et requiert une concentration & une patience à toute épreuve. Il est conseillé de le parcourir en plusieurs fois, équipé d'une bière ou d'une bonne bouteille de vin pour les plus aisés d'entre nous.

”

Introduction

Cette série d'articles donne un éclairage assez avancé sur le fonctionnement du cache eZ Publish, avec un focus particulier sur :

• le « cache des INI » : la mise en cache PHP des settings
• le « cache de template » : la compilation des fichiers *.tpl en *.php
• le « cache de vue » : la mise en cache des contenus stockés dans eZ Publish vers une sortie statique xHTML (ou autre)
• les « cache-block », la mise en cache des « template-block », portions xHTML (ou autre) contenus dans les templates, et hors de portée du cache de vue (pagelayout.tpl, templates des modules personnalisés, etc.)
• le rôle du fichier expiry.php
• le fonctionnement détaillé du script ezcache.php
• une simulation de performance sur les combinaisons d’indisponibilités des différents systèmes de cache
• et autres chapitres susceptible d'être ajoutés lors de la rédaction continu de cet ouvrage

Cette série d'article s'efforce de ne pas expliquer à nouveau ce qui est déjà décrit et compréhensible dans d'autres didacticiels ou documentations officielle, elle a pour vocation :

• D'expliquer comment eZ Publish gère « bas niveau » les fonctionnalités de cache qu'il propose : il s’agit de l’aspect « documentation » des articles
• D'en déduire un possible impact, une possible bonne ou mauvaise pratique dans l'utilisation et la combinaison des paramètres proposés. Il s’agit de l’aspect « tutoriel » des articles

A tous ceux qui considèrent que la gestion du cache eZ Publish est complexe et/ou problématique, il est également nécessaire de considérer les points suivants :

• Ce didacticiel existe (ce qui change tout), merci de le lire, de le critiquer, de le compléter, et de remonter toutes les questions ou erreurs détectées
• eZ Publish est gourmand en ressource (notamment SQL) de part son mode de stockage de données : le concept de classe & le concept d'EAV (entity / attribute / value), c'est le prix à payer pour profiter du concept magique de « classes de contenus », d'une stabilité fonctionnelle ou encore des possibles montées de versions depuis l'origine du CMS (modèle de données stable & universel)
• Les autres CMS « concurrents » ont la réputation de proposer une gestion de cache plus simple à manipuler, tout simplement par l'absence de gestion réelle de cache (généralement un simple TTL, une délégation à Varnish, une absence de cache en mode authentifié...)

Note : Les exemples et mécanismes décrits s'appuient sur la version eZ Publish 4.5+ Enterprise ou eZ Publish 2011.x communautaire

Un tutoriel / documentation pour qui ?

Cette série d'article s'adresse essentiellement :

• aux développeurs / administrateurs ayant une connaissance avancée d'eZ Publish
• aux développeurs de sites à fort trafic ou en recherche de gain de performance
• aux développeurs souhaitant se réconcilier avec leur hébergeur / administrateur de serveurs
• aux éco-citoyens soucieux du nombre d'ampoules grillées (ou de Panda assassinées) lors de la reconstruction des caches de vue ou des caches de template-block

Le cache de INI

Le cache des fichiers INI n’a pas de gros impact sur charge serveur, puisqu’il ne consomme pas de SQL, et assez peu de RAM / CPU. Comme nous le verrons dans ce chapitre, le cache de INI limite essentiellement le volume des I/O, et accélère de façon homogène le temps de construction des pages.

A quoi sert le cache de INI

eZ Publish accepte plusieurs conventions dans le nommage d’un fichier de configuration INI :

• mysetting.ini
  • à la racine de : settings
  • à la racine des extensions : extension/myextension/settings/mysetting.ini
  • à la racine de share/locale
• mysetting.ini.append (progressivement déprécié, à éviter)
• mysetting.ini.append.php pour surcharger un fichier INI dans les différents emplacement dédié :
  • settings/siteaccess/
  • settings/override/
  • extension/myextension/settings/
  • extension/myextension/settings/siteaccess/

La syntaxe exploitée dans les fichiers INI est de la forme :

<?php /*
 
[section]
setting1=value1
array_setting[]=value2
array_setting[]=value3
# ...
*/ ?>
 

La mise en cache permet de transformer cette syntaxe familière en tableau clé PHP hiérarchique, ne nécessitant pas un parsing systématique des fichiers INI

Comment sont générés les caches de INIeZ Publish génère les caches de INI « à la volée » de la façon suivante :

• Le chargement d’un fichier INI est invoqué par un template (ezini), ou l’API PHP (classe statique eZINI)
• Le hash et le chemin du fichier de cache concerné est calculé en amont
• Si le fichier existe en cache, on charge les données :
  • Si EZP_INI_FILEMTIME_CHECK est commenté (par défaut) dans config.php, alors vérification récursive dans toutes les surcharges concernés que les données n’ont pas changées, et sauvegarde d’un nouveau cache le cas échéant
  • Si EZP_INI_FILEMTIME_CHECK est décommenté (et reste à FALSE) dans config.php, utilisation directe des données du fichier de cache, sans vérification automatique de possibles mises à jour

define( 'EZP_INI_FILEMTIME_CHECK', false );
 

Comme le précise la documentaton dans le config.php, décommenté la ligne EZP_INI_FILEMTIME_CHECK améliore les performances puisqu’elle permet à eZ Publish de ne pas vérifier systématiquement la présence de possibles mise à jour dans l’arbre de surcharge des INI (gain en I/O, et gain constaté de 10% à 15% sur le chargement des pages eZ Publish, en fonction des performances I/O du système de stockage) :

eZ Publish stocke le cache des INI (ou plutôt les INI compilés en tableaux PHP) dans le répertoire non modifiablevar/cahe/ini/, de la façon suivante :
{nomdufichierini}-{hash}.php

Par exemple pour les différentes versions de design.ini :

• design-677247a49e428aa0837411b52777b920.php
• design-704216b4d0e3ea68c09742504bb366c8.php
• design-7333039e7e19aa411f8dd01836555861.php

Le hash est calculé à partir des clés suivantes :

Comment faire expirer l'ensemble du cache de INI

L’expiration complète du cache de INI s’effectue de la façon suivante :

php bin/php/ezcache.php --clear-id=global_ini
 

Supprime le répertoire var/cache/ini

php bin/php/ezcache.php --clear-tag=ini
 

Supprime le répertoire var/cache/ini, ainsi que le cache des extensions actives dans /var/cache/active_extensions_{hash}.php

php bin/php/ezcache.php --clear-id=ini
 

Ne fait rien, ou du moins tente de supprimer récursivement un répertoire qui n’existe pas, à savoir {varDir}/ini. Le répertoire ‘var/cache/ini/’ est fixé en dur dans lib/ezutils/classes/ezini.php...

Comment faire expirer un lot de cache de INI

Il n’est techniquement pas possible d’expirer un lot de cache de INI avec les commandes de base d’eZ Publish. Cependant, une expiration ciblée du cache des INI (site.ini par exemple) peut être effectuée par simple suppression des fichiers concernés :

find var/cache/ini -name "site-*" | xargs rm
 

• Tags :
• Cache
• INI
• settings
• eZ Publish