Re: Bug contamination des caches non sessionn és

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

JLuc

Le 04/12/2018 à 13:16, JLuc a écrit :
> Le 30/11/2018 à 09:53, JLuc a écrit :
>> Le 29/11/2018 à 00:55, JLuc a écrit :
>>> je suis tombé hier sur un bug https://core.spip.net/issues/4235
>> À 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.
> 
> JL
> 
> 
> 
> 
>>
>> 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.
>>
>> JLuc
>>
> 
>