Découvertes faites avec XRay

Le talon des squelettes sessionnés

Les -* Les caches sessionnés ont un « talon » = stub, cache creux, sans suffixe _ ni contenu html, qui ne comprend comme métadonnées que l’invalideur session='' et lastmodified. Les talons ne sont pas des caches de squelette, mais des marqueur de sessionnage : ils servent uniquement à indiquer que les caches de ce squelette sont sessionnés (cf source : creer_cache et public_cacher). Et alors, c’est un autre cache qui contient le contenu et les métadonnées du squelette : celui avec le suffixe d’identifiant de session.

Il y a autant de talons qu’il y a de couples (squelette, contexte). Pour chacun de ces talons, il y a autant de caches qu’il y a de sessions.
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 avec les compositions

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. Et si c’est un feature ou si c’est pas possible de remettre ça en cause, on pourrait concevoir une nouvelle forme d’inclusion superdynamique qui ne serait PAS dé-dynamisée lors d’une éventuelle inclusion statique.

Bug ou Feature ?
-  Ça me semble plus un bug qu’un feature. C’est d’une importance limitée car on maîtrise en général bien les situations d’inclusion statique (pour 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.

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 sessionnanement .

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 Le fix a été intégrée dans spip 3.3 dev.
-  Le ticket sur le trac
-  L’analyse )