Carnet Wiki

Découvertes faites avec XRay

Version 5 — Janvier 2021 JLuc

Le microscope a permis de mieux connaître les forces de la Vie et la biologie de nos cellules. Le téléscope a permis de mieux comprendre les lois de l’Univers et du Cosmos. De même, Xray révèle l’intime fonctionnement des inclusions de squelettes et des caches SPIP, dans toute leur magie et leur complexité...

C’est très pratique pour débuguer un jeu de squelettes récalcitrant ou pour optimiser un site, mais cela a également permis quelques découvertes.

Le talon des squelettes sessionnés

Savez vous que les caches sessionnés ont un « talon » ? Ce talon, c’est un stub, un garde-place, un cache creux, sans suffixe _ ni contenu html et qui ne comprend comme métadonnées que l’invalideur session='' et lastmodified. Les talons sont gérés comme les caches mais ce ne sont pas des caches de squelette. Ce sont des marqueurs de sessionnage : ils servent uniquement à indiquer que les caches de ce squelette sont sessionnés. Le source est là : creer_cache et public_cacher.

Ces talons étant vides, c’est un autre cache qui contient le contenu sessionné et les métadonnées du squelette : cet autre cache a l’identifiant de session comme suffixe, ce qui permet de le reconnaître.
Xray permet de filtrer pour ne voir que les talons, et propose des liens pour accéder à la liste de tous les caches ayant le même talon.

Attention à l’explosion : il y a autant de talons qu’il y a de couples (squelette, contexte), et pour chacun de ces talons, il y a autant de caches qu’il y a de sessions. Si vous avez une noisette sessionnée, utilisée pour beaucoup d’objets et par beaucoup d’utilisateurs, il est possible que le cache sature et ne serve plus à rien.

Attention avec les compositions

Les les squelettes des compositions sont appelés par l’inclusion d’un autre squelette avec un argument composition en plus. Le cache résultant a le nom du squelette principal, mais la valeur du squelette associé (champ ’source’ du cache) est le squelette de la composition.

Dé-Dynamisation des inclusions dynamiques

L’inclusion d’un squelette statique dé-dynamise tous les caches des inclusions dynamiques faites par ce squelette.
Exemple : Si A #INCLUE B qui <INCLUE> C, alors C est en fait inclu statiquement dans B et donc dans A. Une conséquence est que si C est sessionné, alors B et A le sont aussi (confirmation par Cerdic).

Bug ou Feature ?
-  Ça me semble plus un bug qu’un feature. La gravité est limitée car on maîtrise en général bien les situations d’inclusion statique (et on peut les limiter).
-  Si c’est un feature ou si c’est pas possible de remettre ça en cause, on pourrait concevoir une nouvelle syntaxe permettant des inclusions superdynamiques, c’est à dire que ces inclusions ne seraient PAS dé-dynamisées lorsque le squelette incluant est inclu statiquement. Ça fait partie des pistes de développements futurs pour le plugin macrosession).

Quand un modèle sessionné est inséré dans le champ éditorial d’un objet

Quand un modèle sessionné est inséré dans le champ éditorial d’un objet, c’est le squelette affichant ce dernier qui est sessionné. L’inclusion du modèle est statique, pareil qu’avec #INCLURE. Le modèle n’a pas de cache du tout. Normalement, on peut avec SPIP3 spécifier une durée de cache pour le modele, mais avec SPIP 3.1.8 je ne vois aucun effet sur la durée du cache du squelette incluant donc je me demande si ça marche ou comment ça se passe.

Les squelettes appelés comme en tant que page d’une url

Les squelettes appelés comme en tant que page d’une url se distinguent de ceux appelé via un INCLURE : leur nom de cache se termine en plus par un suffixe. Au minimum ce suffixe est un simple /, mais d’autres chaines sont possibles. Le même squelette, appelé par un INCLURE, n’a pas ce / à la fin, même s’il a le même environnement.

Le suffixe semble être une sorte de slug relatif à l’url utilisée pour l’affichage de la page : par exemple /spip ou /1234 où 1234 est le N° de l’objet éditorial :
-  ...8b79-gis_json/spip pour le cache de gis_json.html
-  ...928-compte/spip
-  ...f921a-saisies.css/spip
-  ...fe22-mestrucs/spip
-  ...a40f-backend/spip
-  ...a12b-untruc/1234

Bug SPIP (corrigé) : Contamination des caches non sessionnés

Si dans un squelette ya une suite d’INCLURE dynamiques non sessionnés avec au milieu d’eux un inclure sessionné, plusieurs inclusions aprés l’inclure sessionné étaient aussi, indûement, sessionnés. D’autres types de circonstances provoquaient la création de caches sessionnées alors qu’ils ne devraient pas l’être, et induisant une explosion du cache, nuisant aux performances du site.

Ce bug n’impactait que les sites ayant au moins un cache sessionné, c’est à dire une #SESSION, un #AUTORISER, un #URL_ACTION_AUTEUR, un #BOUTON_ACTION dans un squelette, qui contaminait le reste des caches en en forçant le sessionnement.

XRay a permis de détecter ce bug qui était passé inaperçu, quand bien même il nuisait aux performances des sites, et a également facilité la mise au point de la correction. La correction a été intégrée dans spip 3.3 dev.
-  Le ticket sur le trac
-  L’analyse )