Carnet Wiki

Mode d’emploi de Cachelab

Version 4 — il y a 5 jours JLuc

BROUILLON BROUILLON EN CHANTIER

Ce article indique coment utiliser l’API Cachelab et les autres outils pour définir et imprémenter, sur un site particulier, une stratégie d’invalidation du cache SPIP

Exemple d’usage de cachelab_cibler

Le site où ce plugin est développé et mis en œuvre gère des objets « truc » dont l’internaute peut constituer une sélection (des favoris), et dispose d’une partie protégée servant pour l’administration.

Voici 2 modifications réalisées pour cibler les invalidations :

  • Dans l’administration (squelettes dont l’accés est restreint), les modifications de contenu portant sur des « trucs » sont parfois fréquentes, voire continues. Le souhait est que ces modifications ne vident pas tout le cache.
    De manière très classique, un truc est affiché (que ce soit dans la partie publique ou dans l’admin) soit de manière résumée dans des listes (le titre, éventuellement le logo, le sous titre ou une autre caractéristique), soit sur des pages qui lui sont dédiées. Dans tous les cas, des noisettes sont utilisées et en pratique, ces noisettes reçoivent toujours l’identifiant du truc dans leur environnement. Il a donc été très facile de cibler les caches sans devoir réécrire le squelette. Il a suffit de modifier le début et la fin de la fonction ’traiter’ du formulaire #FORMULAIRE_EDITER_ADMIN_TRUC :
    -  un appel à controler_invalideur('stop') en début de fonction, et un appel à controler_invalideur('go') en fin de fonction permettent d’éviter toute invalidation « par défaut » pendant le traitement.
    -  Juste avant le retour du traiter, on invalide tous les caches contenant le truc modifié avec cachelab_cibler('del', array('cle_objet'=>'id_truc', 'id_objet'=>$id_truc))
function formulaires_editer_truc_admin_traiter_dist($id_truc) {
// On commence par désactiver l'invalidation des caches par SPIP
    include_spip('inc/cachelab');
    controler_invalideur('stop');
 
 
// ... code du traitement
 
 
// Quand le traitement est fait, on invalide les caches le nécessitant  
    cachelab_cibler('del', array('cle_objet'=>'id_truc', 'id_objet'=>$id_truc));
// et on restaure le mécanisme d'invalidation habituel :
    controler_invalideur('go');
    return $res;
}
  • Pour ce site, l’internaute logé peut se constituer une sélection de trucs. Pour cela, un formulaire
    #FORMULAIRE_SELECTION

    lui permet d’ajouter un truc à sa sélection, ou de le retirer s’il y est déjà. Il utilise pour cela la structure de donnée et l’API fournie par le plugin mesfavoris. La fonction de traitement du CVT de ce formulaire désactive l’invalidation SPIP des caches et provoque l’invalidation des seuls caches périmés :

function formulaires_selection_traiter_dist($id_truc) {
    include_spip('inc/cachelab');
    controler_invalideur('stop');
 
 
$res = array('message_ok'=>' ');
    $id_favori = ;
 
// ... traitement du formulaire ...
 
 
// $id_favori vaut maintenant l'identifiant du favori créé ou supprimé
// on invalide tous les caches concernés et on restaure le fonctionnement normal du cache
    cachelab_cibler( 'del', 
                              array(	'chemin'=>'selection', 
                                        'cle_objet'=>'id_favori', 
                                        'id_objet'=>$id_favori )
                            );
    controler_invalideur('go');
    return $res;
}

Ici, la présélection par le chemin permet de ne pas interroger le contenu de tous les caches qui n’ont pas de rapport avec les sélections.

Un 3e usage est fait dans l’action instituer_truc.

Un 4e usage est fait dans ...

Ensuite, il ne reste plus que les invalidations SPIP suivantes à gérer :
-  pour la création d’un point GIS lors de la création d’un nouveau ’truc’ dans le public (facile à éviter), ou lors de la modification de l’adresse d’un ’truc’.
-  lors du cron mailsubscriber pour la mise à jour des listes de diffusion dynamiques, au milieu de la nuit (facile à éviter, mais c’est pas forcément gênant).
-  lorsqu’un internaute crée sa fiche « auteur »
Ces invalidations sont alors gérées et fortement ciblées au moyen des autres outils proposés pour les objets et événements.

Stratégie de mise en oeuvre sur votre site

Cette partie porte uniquement sur l’usage de l’API cachelab_cibler . D’autres outils ont été développés depuis

L’usage dépend de chaque site.

Voici 2 marches à suivre pour concevoir comment utiliser CacheLab sur un site existant. Les 2 approches sont complémentaires et peuvent se combiner pour couvrir la totalité des cas d’invalidation à cibler.

Autre usage potentiel : pour un objet standard

Pour un objet déjà existant dans SPIP (par exemple article, forum, etc), la modification d’une valeur se fait via le formulaire d’édition livré avec SPIP, et appelle les pipeline pre_edition et post_edition : il sera possible de définir ces pipelines de manière à désactiver l’invalidation des caches, puis appliquer l’invalidation sélective désirée, et enfin réactiver l’invalidation normale des caches.

Cachelab permet toutefois des manières de faire ça plus simplement dans un grand nombre de cas : l’API pour les objets et événements.

Approche « formulaires »

-  Déterminer quelles sont les circonstances d’invalidation par défaut. En général, c’est un formulaire qui modifie la base de donnée. Pour s’assurer que le site soit mis à jour, le traitement des formulaires appelle la fonction suivre_invalideur du noyau SPIP. Cet appel a lieu soit directement dans la fonction ’traiter’ du CVT, soit dans l’une des fonctions d’API SPIP appelées à l’intérieur de ce ’traiter’.

-  Déterminer quelles sont les parties du site dont il est critique qu’elles soient immédiatement mises à jour, et inversement, quelles parties peuvent supporter un délai normal d’invalidation du cache avant d’être mises à jour. La nature du site, les circonstances de son utilisation, la fréquence des pics de consultation ou de création de contenu, la mesure des temps de calculs des caches fournie par var_profile=1, l’usage de la partie privée ou d’une partie d’administration, ... sont des paramètres à prendre en compte.

-  En conséquence, choisir quels caches doivent être invalidés dans cette circonstance, et lesquels il est inutile d’invalider.

-  Si nécessaire, restructurer l’arborescence des squelettes de manière à pouvoir spécifier plus facilement, au moyen de l’argument $chemin ou $id_objet, quels sont les caches qui doivent être invalidés dans ce cas. Certaines bases de squelette standard contiennent déjà des sous-répertoires liste ou admin, qu’il est déjà possible d’utiliser, mais vous pouvez créer à volonté les chemins utiles pour la stratégie définie, quitte à renommer un dossier ou un squelette pour plus facilement le cibler. Il est aussi possible de passer un environnement spécifique à un squelette {marqueur_cachelab=iciprecis} pour le cibler précisément.

-  Dans tous les cas il faut privilégier le filtrage par chemins, qui est beaucoup plus efficace que le filtrage par contenu du contexte. En effet, le filtrage par chemins ne nécessite pas de récupérer la valeur du cache : il suffit d’en tester la clé. Lorsqu’on veut tout de même filtrer en fonction de la valeur d’un identifiant d’objet, on aura donc intérêt à faire un pré-filtrage par le chemin dans le squelette.

-  L’onglet « Cache Lab » de XRay permet de tester les conditions envisagées.

-  Réécrire la fonction traiter de ce formulaire afin de ne pas appeler suivre_invalideur, mais labcache_filtre('del', ...) avec les conditions que vous avez défini.

Ce travail étant fait, le plugin XRay permet de vérifier que le formulaire corrigé n’invalide plus la totalité du cache, mais seulement les caches ciblés.

Approche « objet »

-  Concevoir pour chaque cas d’invalidation une stratégie de ciblage des caches
-  Définir les fonctions implémentant cette stratégie et l’activer via l’API d’invalidation par objet ou événement invalidant. (à documenter)