Re: [SPIP Zone] Plugin de cache efficace

From : JLUC@... , the 6th March 2018 04:59

Le 11/02/2018 à 20:47, cedric@... a écrit :
 Voilà tu commences à rentrer dans le sujet : c’est une voie qui commence par  « oh ce serait pas très compliqué et bien plus efficace »  et très vite on arrive à « ah mais oui mais il y a aussi ces cas là à gérer et… »  et ça finit en usine à gaz.
Là où je suis rentré dans du plus compliqué, c'est en imaginant de gérer des listes spécialisées de caches, qui seraient automatiquement mises à jours à la création des caches, et dont les caches seraient automatiquement invalidés après certaines modifications. Ça suppose que chaque jeu de squelette définisse des règles de sélection pour constituer les listes, une gestion globale des listes et une surcharge plus large du noyau spip. Mais ça, ça vient en plus, en prime, et le reste semble assez simple. Ça ne semble pas absolument nécessaire puisque sans ça, on gagne déjà un ou 2 ordres de grandeur en efficacité en travaillant en mémoire, par rapport à travailler avec des filecaches, et que ce gain permet de filtrer tous les caches à la recherche de ceux à invalider. Mais par ailleurs, il me semble que ces listes ont un autre intérêt (qui m'a décidé à rédiger ce mail) : c'est qu'une telle gestion de listes pourrait *aussi* servir pour les spip avec filecaches (sans mémoïzation en mémoire vive). Car sans ces listes de présélections, il est trop coûteux de filtrer tous les filecaches pour trouver ceux à invalider, mais avec ces listes, ça devient possible même avec filecache puisqu'il n'y pas de perte pour le filtrage : il faut invalider tous les caches contenus. Sous réserve de tester, ça élargit beaucoup le champ d'application.
 J’ai pas voulu en rajouter, mais nulle part tu ne traites le problème de « si je modifie l’article 18 ça impact aussi   des pages qui n’ont pas id_article=18 dans le contexte, comme par exemple la rubrique parente, la home etc. »
Si tout à fait. Ça me donne l'impression que tu réponds sans vraiment avoir lu. Ces situations sont traitées par la possibilité d'invalider tous les squelettes dont le chemin contient une certaine chaîne. En l'occurence, les 2 exemples que tu évoques contiennent des listes d'articles : la rubrique parente est une liste d'articles, de même que la home (entre autres choses). En concevant le squelette, on peut ranger tous ces fichiers squelettes dans un répertoire dont le nom contient la chaine 'liste', ou leur donner un nom de fichier contenant la chaine 'liste'. Ensuite, il suffit de passer 'liste' en argument $chemin de la fonction cachelab_filtre pour que tous ces caches soient invalidés. cf https://zone.spip.org/trac/spip-zone/browser/_plugins_/xray/trunk/cachelab.php#L99 Toutes les listes sont alors invalidées. C'est plus que nécessaire, mais c'est moins que si on invalide tous les caches, et la finesse du crible peut se gérer comme on veut, à la louche, à la petite cuillère ou au plus juste avec un tamis fin, selon la prise de tête consentie dans l'analyse des besoins des squelettes, ou selon la puissance du serveur dont on peut librement disposer à perte.
 Si tu veux vraiment aller par là tu peux difficilement faire l’impasse sur le plugin Reresher  https://contrib.spip.net/Refresher  qui traite du même sujet et qui est un bel exemple de la complexité à laquelle on arrive vite :)
En effet, c'est pas simple. refresher est conçu pour les filecache, et quand on fonctionne en mémoire, certaines complications sont inutiles car les parcours de caches sont beaucoup plus rapides. Je vois que pour le Pull, il faut définir des règles comme dans le mécanisme plus avancé des listes précalculées. Je sais pas si je poursuivrai, car on me dit que sur un bon hébergeur tout ceci n'est pas nécessaire (à confirmer !), mais j'ai fait un etat des réflexions sur le carnet wiki : https://contrib.spip.net/cachelab JL