Carnet Wiki

API CacheLab : Exemple et stratégie d’invalidation ciblée

Version 9 — il y a 4 mois — 78.242.xx.xx

BROUILLON

Ce article partage des exemples d’utilisation de l’API Cachelab pour définir et implémenter une stratégie d’invalidation du cache SPIP

- l’API de niveau 1 est plus facilement utilisable lorsqu’on construit un site internet et son code : formulaires et actions.
-  l’API de niveau 2 permet de plus facilement intervenir lorsqu’on veut intervenir sur un site existant, sans devoir modifier le code existant.

Exemple d’usage de cachelab_cibler sur un site existant

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 avec le plugin « favoris », et dispose d’une partie protégée servant pour l’administration.

Voici quelques unes des 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 et il arrive qu’elles se fassent en continu. Sans cachelab, le cache est en permanene invalidé : c’est comme si le site fonctionnait sans cache. 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, le logo, le sous titre ou une introduction), 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 « spip 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.

D’autre usages se trouvent dans l’action instituer_truc, ...

Exemple d’usage de l’API de niveau 2 sur un site existant

Sur ce même site, il ne reste plus ensutie que les invalidations SPIP suivantes à gérer :

Ensuite , il ne reste plus que les invalidations SPIP suivantes à gérer  : - 1 ) 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.

- 2) lors du cron mailsubscriber pour la mise à jour des listes de diffusion dynamiques, au milieu de la nuit. La synchro des listes dynamiques de mailsubscriber se fait automatiquement entre 00h00 et 01h00 et appelle automatiquement l’invalidation SPIP (cf #1464). Si on veut éviter cette invalidation totale quotidienne, il faut penser à intercepter cette invalidation.

Les exemples de code codes pour 1 ) et 2 ) ces parties sont cités comme exemple dansl’article [->5151] 5151 ].

-  3 ) lorsqu’un internaute crée, modifie ou détruit sa fiche « auteur »
Ces invalidations sont alors, elles aussi, ciblées au moyen de l’API de 2e niveau :

function cachelab_suivre_invalideur_auteur($cond, $modif) {
	if (!preg_match(',["\']([a-z_]+)[/"\'](.*)[/"\'],',$cond, $r)) {
		spip_log ("Pas reconnu cachelab_suivre_invalideur_auteur($cond, $modif)", "cachelab_erreur");
		return $modif;
	}
	list ($ignore, $objet, $id_auteur) = $r;
	spip_log ("on invalide pour auteur $id_auteur (objet $objet) suite $cond", "cachelab");
	include_spip ('inc/cachelab');
        cachelab_cibler('del', array ('chemin'=>'auteur|compte|liste'));
 
 
return false;
}

Stratégie de mise en oeuvre sur votre site

L’usage dépend de chaque site. Les 2 approches sont complémentaires et peuvent se combiner pour couvrir la totalité des cas d’invalidation à cibler.

Pour un objet standard

Avec l’API d’action ciblée locale : 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 avec l’API d’invalidation ciblée globale.

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 <code>labcache_cibler(’del code>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 globale d’invalidation ciblée.