Carnet Wiki

Version 2 — October 2018 JLuc

Notes de développements

<blockquote class="spip">

Voir aussi
-  Archives : statistiques cachelab
-  XRay, un explorateur des caches SPIP
-  API CacheLab 1. Action sur des caches ciblés

</blockquote>

Investiguer dans spip core


-  Est il “normal” que certains caches soient vides (pas même de métadonnées) ou bien est-ce peut être un bug SPIP ? ça peut être des marqueurs (stubs) servant à déclancher une redirection plus précise ensuite (cache sessionné).
-  Est il “normal” que le nom de certains caches se termine par ’_’ ? Cerdic semblait dire que non.
-  Le _CACHE_NAMESPACE, qui pour Memoization identifie le site, varie parfois, car son calcul est basé notamment sur le port, qui varie parfois. Idéalement, il faudrait purger aussi les caches correspondant à d’anciens _CACHE_NAMESPACE car ils ne seront probablement plus jamais utilisés. C’est pas dramatique de pas le faire car APC finira bien par jeter ces caches qui ne sont plus utilisés. TODO : gérer les “aliens” dans les stats et parcours Xray

Explorations plus lointaines

Extension envisageable : listes ciblées préfiltrées

Une possibilité serait de constituer des listes ciblées : sous-ensembles pré-filtrés de caches. Une telle liste de caches serait alimentée au moment de la création d’un cache, lorsque ce dernier satisfait les critères définissant la liste. L’invalidation sélective pourrait alors directement spécifier les caches de quelle liste doivent être invalidés, en paramètre de suivre_invalideur.
-  Il y aurait un surcoût lors de la création d’un cache, pour préfiltrer le cache. Mais ce surcoût semble très réduit.
-  Les temps d’invalidation seraient alors énormément réduits (divisés par un facteur 100 ou 1000 ?), puisqu’il n’y aurait aucun filtrage requis. Tout le parcours serait utile.

Cette possibilité semble peu intéressante lorsqu’un cache mémoire est utilisé, mais serait intéressante pour filecache, lorsque le cache se fait sur le disque. Car le parcours de tous les fichiers de cache sur le disque est trés coûteux, mais on ne perd pas de temps si on garde précisément la trace des caches qu’il faut invalider (parcours 100% utile).

Ces listes sont en fait une extension de ce que propose le plugin microcache. Il serait probablement possible de l’implémenter en étendant microcache (en ajoutant un nouvel argument à la fonction : le nom de la liste de caches ciblés (qui décrit aussi le type de filtrage qui génère cette liste).

Ajouter un ou des pipelines

S’ils étaient implémentés dans le core, dans les fonctions de gestion du cache, des pipelines permettraient d’implémenter des stratégies alternatives de fonctionnement du cache, sans surcharger tout le fichier dans un plugin.
-  suivre_invalideur
-  la fonction qui vérifie si un cache existe et est à jour
-  un cron : revenir sur la suppression du genie invalideur

Cachecool

On pourrait au contraire souhaiter garder les caches invalides et les utiliser à la demande, comme fait cachecool. Cela n’atténue pas la charge sur le serveur, mais ça donne l’impression d’un service plus rapide.

On peut combiner :
-  les caches périmés sont supprimé par cron toutes les X minutes
-  dans l’intervalle, les caches périmés sont quand même servis. L’utilisateur doit être averti qu’il doit parfois attendre un peu pour que les affichages soient mis à jour ou disposer d’un bouton pour forcer la mise à jour de la noisette qui l’intéresse !