Carnet Wiki

Version 2 — March 2018 JLuc

Laboratoire du cache

Cachelab permet d’expérimenter et tester diverses stratégies de cache lorsqu’on emploie mémoization et un cache en mémoire : APC, memcache, redis aussi peut être

L’expérimentation porte surtout le ciblage de l’invalidation du cache

cachelab.php est un fichier du plugin xray qui commence à implémenter les fonctions utiles. Il est valable, pour l’instant, uniquement pour APC cache mais vise à passer par l’API de memoization et donc être disponible pour toutes les mémoizations en mémoire.

Les fonctions cachelab_filtre et cachelab_applique permettent d’invalider sélectivement une liste de caches selon plusieurs critères :
-  présence d’une chaine dans le chemin du squelette.
-  présence d’une variable avec une certaine valeur dans l’environnement du cache.

Lors des tests on obtient des temps de filtrage sont de l’ordre de 0.1 à 0.5 secondes lorsqu’il y a 10000 à 20000 caches en mémoire. C’est supportable lorsque le filtrage et l’invalidation n’ont lieu qu’à la demande lorsqu’on crée ou modifie un contenu, mais il serait intéressant tout de même de limiter cet impact.

Stratégies possibles

En l’état actuel, 90% des caches sont périmés en général. Il serait intéressant de les effacer et de ne retenir que les caches valides. On diviserait les temps moyens par 10.

Ce garbage collector peut se faire soit au fur et à mesure qu’on découvre des caches invalides, soit globalement en cron.

On pourrait au contraire souhaiter les garder, mais 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 2 approches :
-  les caches périmés sont supprimé par cron toutes les X secondes ou 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.

Selon les sites et les objets

Les stratégies d’implémentation dépendent des sites et des objets utilisés.

Il semble possible 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 possible toutefois pour les squelettes généralistes de SPIP : dist, spipr, escale, SC, sarka...