Re: [SPIP Zone] Plugin de cache efficace

From : JLUC@... , the 8th February 2018 12:14

Merci cerdic et marcimat pour vos réponses qui me permettent de voir les limites du truc et comment préciser aussi. Je répond ci après et commence à tester. Le 07/02/2018 à 17:17, cedric@... a écrit :
 Tu fais allègrement l’impasse sur mon calcul d’ordre de grandeur qui te montre justement qu’entre invalider un cache toutes les 10min et invalider un cache toutes les 6 heures tu optimise tout au plus 0.2% de tes hits.  Même en supposant qu’un hit calcul est 10 fois plus couteux qu’un hit en cache, ça te fait un gain potentiel sur tes ressources serveurs de l’ordre de 2%, cela en supposant que ton énergie dépensée à gérer ton invalidation est nulle.
Effectivement je n'ai pas encore bien intégré ces ratios. En pratique tout de même, l'efficacité n'atteint pas souvent de 98,5%. Notamment pendant un usage intensif de l'admin-privé-backend, les invalidations sont très fréquentes (une par minute par exemple). Typiquement dans ce cas il serait utile de n'invalider que les squelettes de l'admin - on peut affiner et préciser quelle partie de l'admin doit être invalidée -.
 Moi je sais pas trop comment avec memoization tu fais pour dire « hé invalide moi tous les caches qui correspondent à l’article 18 » vu que justement c’est un système de stockage clé-valeur, donc tu n’as pas de relationnel ni de structure de requêtes pour ressortir un lot de cache etc.
Avec memoization on a un accés rapide au contexte (et à toutes les métadata) associées à un cache. Il suffit de les passer tous en revue et voir s'il y a id_article=18 dans le contexte. ça aurait été hyper lent avec filecache mais ça semble raisonnable avec APC Cache (ou memcache ou reddis probablement). Dans le cas où on veut invalider les squelettes d'un certain sous-dossier, il n'y a pas besoin d'accéder au contexte, il suffit de tester le nom du cache, qui intègre le chemin du cache. D'où la proposition : que suivre_invalideur reçoive un argument du format "id='objet/id_objet' chemin='regexp_nomducache'" Dans mon cas pour le backend il faut tester s'il ya la chaine 'admin' dans le chemin. Dans le cas du privé de spip, j'ai l'impression que la chaine 'prive' ne suffit pas (la chaine 'prive' ne se retrouve dans le nom du cache que si c'est une noisette perso pour le privé) Mais s'il y a à disposition un mécanisme d'invalidation ciblée comme ça, on peut aussi, ensuite, construire les squelettes en conséquence. Par exemple, dans mon cas, les squelettes de listes d'objets sont dans un dossier 'liste' : ça tombe bien car c'est facile à cibler pour invalider chaque fois qu'on crée ou modifie un objet. Pour les caches qui sont repérés, on pourrait probablement les invalider spécifiquement en ajoutant un champ 'valide' dans les metadata (à tester dans la fonction qui vérifie la validité d'un cache) mais en tout cas il est facile de les vider simplement (mais au détriment de cachecool) et c'est ce que j'envisageais jusqu'à maintenant. Par exemple si on veut que tous les squelettes de listes d'objets se mettent à jour dans le public ainsi que les squelettes avec id_article=18 dans le contexte ainsi que tout l'admin et le prive on pourrait demander suivre_invalideur("id='article/18' chemin='liste|admin|prive'")
 Maintenant si il s’agit de gérer le passage de certains pics de charge uniquement, tu peux avoir une stratégie relativement triviale et peu couteuse qui consiste à dire « si mon serveur est plus chargé que tel seuil et que j’ai un cache disponible qui date de moins de 24h je le considère valide même si mon flag derniere_modif me dit que normalement je devrais le mettre à jour »
En effet, ça semble assez simple à mettre en place.
 Avec ça ton site fais le gros dos quand tu as un pic de charge et fonctionne nominalement le reste du temps.  Mais si ton serveur est constamment trop chargé tu perd l’invalidation du cache liés aux modifications éditoriales (et c’est là qu’il est important d’avoir quand même un délai maxi sur le cache, pour assurer que ton site se mettra quand même un peu à jour)
Pour apprécier "l'énergie" mise pour un filtrage je vais tester le coût d'un filtrage de cache selon les critères "id_objet dans le contexte" et "chemin dans le nom" (pour invalidation ciblée ou vidage ciblé) JL