Version 5 — Octobre 2018 — JLuc
Notes de développements
<blockquote class="spip">Voir aussi
- Doc du plugin : API CacheLab 1. Action sur des caches ciblés
- Archives : statistiques cachelab
- XRay, un explorateur des caches SPIP
Caches ’aliens’ et autres non traités
APC Cache gère les caches de SPIP pour ce site, mais aussi, selon la configuration serveur, les caches APC d’autres origines. Ces caches APC peuvent être créés et gérés par :
- d’autres sites SPIP ou non SPIP sur le même serveur si celui ci communalise le cache APC (n*t)
- ce même site SPIP mais interrogé sur un autre port (car le _CACHE_NAMESPACE, qui pour Memoization identifie le site, est basé notamment sur le port). Ça se produit par exemple si votre site mélange les accès http et https.
cacheLab compte et renvoie dans nb_alien le nombre de ces caches mais n’y touche pas du tout (il ne les efface pas).
Parmi les caches APC autochtones, un certain nombre de caches APC ne sont pas créés pour des squelettes : il y a notamment les caches des déclarations textwheel. Ces caches ne sont pas comptés et ne sont pas traités par cacheLab.
crons invalideurs
La synchro des listes dynamiques de mailsubscriber se fait automatiquement entre 00h00 et 01h00 et appelle automatiquement l’invalidation SPIP (cf #1464). D’autre crons potentiellement aussi.
C’est pas forcément gênant car ça se passe de manière groupée au cœur de la nuit : on peut accepter que les caches soient systématiquement remis à 0 une fois par jour, à un moment de moindre fréquentation du site.
Si tout de même on veut éviter cette invalidation intempestive, on peut surcharger newsletter_subscribe_dist pour stopper l’invalidation spip avant d’appeler objet_modifier, puis la restaurer.
- 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.
Il semble assez facile de déployer une stratégie optimisée dans le code php qui implémente un objet lorsque ce code est conçu « sur mesure » pour un site donné. Ça semble plus difficile pour des objets génériques qui ne préjugent rien du contexte d’utilisation. La stratégie par défaut de SPIP à l’heure actuelle reste peut être bien la meilleure dans ces cas là.
Un entre-deux semble envisageable pour les squelettes généralistes de SPIP : dist, spipr, escale, SC, sarka... Certains se prêtent certainement bien à l’élaboration d’une stratégie optimisée de ciblage.
On pourrait également définir des conventions génériques de nommage des dossiers et fichiers permettant d’implémenter des régles standard de filtrage et invalidation ciblée du cache. Sur la base de ces conventions, on pourrait définir un plugin standardisé auquel auraient recours les squelettes se conformant aux conventions et souhaitant bénéficier de l’invalidation sélective du cache.
Exemple de règles :
- nom de dossiers contenant ’liste’, ou plus précisément ’liste_monobjet’, pour les noisettes qui présentent des listes de monobjet et qui doivent être invalidées lorsqu’on crée, supprime ou modifie un monobjet
- noms de squelettes contenant ’monobjet’ lorsqu’il faut filtrer pour les invalider sélectivement lorsqu’on crée, supprime ou modifie un monobjet avec un id_monobjet particulier
De même, il semble intéressant de chercher à fournir des comportements optimisés standard pour certains plugins :
- mesfavoris
- gis
- formidable ?
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).
Disponibilité pour filecache et autres
Pour filecache et les caches mémoires autres que APC, il faudra probablement implémenter une gestion de la liste des caches, car je crois qu’ils n’en disposent pas en natif.
À faire donc : une nouvelle méthode de memoïzation qui permette de parcourir les caches. La création de la liste est activée sur demande explicite seulement (paramétrable par define).
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->https://core . spip.net/projects/spip/repository/revisions/23896]
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 !