Poursuivant mes investigations avec xray et cachelab
je suis tombé hier sur un bug https://core.spip.net/issues/4235
assez pénible puisqu'il provoque la multiplication des caches sessionnés pour rien.
Peut être d'ailleurs est il à l'origine des explosions de cache parfois signalés.
J'ai peut être un fix, mais la gestion des caches est complexe
et je ne suis pas certain de maîtriser tous les aspects :
à part dans le cas des inclusions statiques, y a t il un cas
dans lequel le fait qu'un cache soit sessionné
doit aussi contaminer (et sessionner) les caches d'autres squelettes ?
Et sinon y a t il des jeux de test pour ces situations de caches sessionnés ou non
et de propagation du sessionnement ?
J'ai testé un fix un peu simple et ça solutionne le pb pour les inclusions dynamiques,
mais c'est trop violent pour les inclusions statiques
puisqu'elles ne contaminent plus leur contexte appelant.
À tester : compléter le fix1 en :
- au moment de l'appel du recuperer_fond d'une inclusions statique, passer une nouvelle option "statique=>true"
- en sortant du recuperer_fond, tester cette valeur et ne pas écraser la valeur du drapeau global si elle est présente.
Ceci fait, il faudrait peut être encore faire le ménage dans la gestion historique
du drapeau, dont une partie ne servira peut être plus.
Et sinon y a t il des jeux de test pour ces situations de caches sessionnés ou non
et de propagation du sessionnement ?
J'ai réalisé 2 jeux de test pour les situations d'inclusions statiques et dynamiques.
Il me semble que ça couvre toutes les situations concernant ces 2 cas
(mais ça ne couvre pas les formulaires par exemple, ou d'autres).
Le tableur en fichier joint décrit les 2 jeux et présente dans chacun des cas
la manière avec laquelle SPIP sessionne les noisettes,
et la manière cible selon moi (= quand il n'y a pas de bug)
- avec le core (3 + 3 erreurs)
- avec le fix (1 erreur : cas décrit ci dessus d'une inclusion statique contaminante)
- la cible dans l'idéal (à mon avis).
Pouvez vous me dire si vous pensez que je fais une erreur, sur les valeurs désirées du sessionnement ?
Car je voudrais m'assurer que je vise la bonne cible.
À tester : compléter le fix1 en :
- au moment de l'appel du recuperer_fond d'une inclusions statique, passer une nouvelle option "statique=>true"
- en sortant du recuperer_fond, tester cette valeur et ne pas écraser la valeur du drapeau global si elle est présente.
Voilà c'est fait et un nouveau fix est proposé, qui satisfait le jeu de test
et assure le bon calcul du sessionnement des noisettes <INCLUES{dynamiquement}>
et #INCLUES{statiquement}{avec la balise #INCLURE}.
Pour qui est intéressé, la dernière version du plugin cachelab permet
de facilement tester le sessionnement des inclusions dynamiques
en passant simplement ?var_mode=cache ou ?var_cache=oui dans l'url
(et en recalculant en même temps, ça aide parfois).
Il n'y a pas besoin pour cela du Cache APC ni même de Memoization.
Pour la suite de #4235, la question se pose aussi avec les appels des modèles :
- pour #MODELE dans un squelette il serait peut être nécessaire d'appliquer la mm soluce que pour #INCLURE
- avec les insertions <modeles> dans un contenu éditorial. Faudrait voir.
Les #MODELES ont toutefois des particularités (« absence de cache propre » hmmm...)
dont je n'anticipe pas les conséquences pour le calcul du sessionnement
et des contaminations de leurs environnements.
J'ai regardé le nombre de squelettes sessionnés ou non,
sur un site qui utilise modérément les sessions :
Sans le fix, il y a 42 squelettes sessionnés,
mais la majorité sont sessionnés sans raison.
Avec le fix, il n'y a que 5 (cinq) squelettes sessionnés.
Ce sont eux qui contaminent 37 autres squelettes dans la version sans fix.
Pour tous ces squelettes sessionnés, le cache ne fonctionne plus chaque fois qu'un nouvel internaute se connecte sur le site. En se privant ainsi des caches pré-existants, tous les calculs doivent être refaits pour chaque internaute logé, alors qu'on sait qu'ils mènent au même résultat. C'est d'autant plus dommage qu'en même temps que la perte d'efficacité, le nombre de caches augmente ainsi que le volume de cache puisque pour chacun des internautes connectés il y a une nouvelle version identique de chacun des 42 squelettes sessionnés.
Des spipeurs ayant un site qui utilise #SESSION ou #AUTORISER voudraient ils tester le fix sur leur site ? https://core.spip.net/issues/4235
! la branche actuelle de cachelab n'est plus compatible
avec les révisions >= 24215 de SPIP3.3dev
le temps de proposer une nouvelle branche de ce plugin.