XRay, un explorateur de cache

Ce plugin est construit à partir du browser de cache APC. Il lui ajoute une surcouche dédiée aux squelettes de SPIP lorsqu’ils sont gérés par Mémoïzation avec le cache APC. Il intègre par ailleurs une page de test et mise au point pour ’labcache’, l’invalideur sélectif de caches.

Ce plugin est construit à partir de apc.php, le browser de cache APC.
Il lui ajoute une surcouche dédiée aux squelettes de SPIP lorsqu’ils sont gérés par Mémoïzation avec le cache APC.

Il intègre par ailleurs ’labcache’, un laboratoire d’exploration de stratégies d’invalidation ciblées du cache.

Le script apc.php fourni avec le cache APC permet
-  de lister les caches et faire des recherches sur le nom des caches
-  de zoomer sur l’un d’eux. Comme le contenu des caches SPIP est sérialisé, c’est peu lisible.

Le plugin adapte ce comportement pour SPIP et propose des outils permettant de mieux analyser les caches squelettes de votre site afin de les optimiser.

On y accède par une entrée du menu « Squelettes ».

Prérequis

-  Votre hébergement doit proposer un cache APC
-  Vous devez avoir installé et activé le plugin memoization avec APC
-  Le « cache user » de APC ne doit servir que pour les caches SPIP avec memoïzation.

Liste

La liste présente pour chaque cache

  • son nom. Pour une meilleure lisibilité, le plugin n’affiche pas le préfixe de _CACHE_NAMESPACE que memoization leur ajoute systématiquement.
  • sa taille
  • le nombre de hit, permettant de jauger l’efficacité du système de cache
  • la dates de création
  • la durée
  • etc

On peut trier la liste selon chacun de ces critères.

Si c’est le cache d’un squelette pour la session d’un visiteur identifié, un bouton ’session’ apparaît à droite : ce bouton permet d’accéder à la liste de tous les caches sessionnés de ce même visiteur.

Affichages extra

Un menu déroulant permet d’afficher certaines infos pour chacun des caches listés :

  • tout le contexte d’environnement utilisé par ce squelette, sous la forme du source d’un tableau php. Lors qu’il n’y a pas de contexte, le texte « (non défini) » est affiché.
  • seulement le contexte spécifique à ce squelette (sans afficher les contextes techniques)
  • le code HTML généré par le squelette SPIP. C’est le contenu utile du cache. Seuls les 1000 premiers caractères sont montrés. Pour voir tout, il suffit de cliquer sur la clé du cache.
  • le contexte relatif à spip_auteur seulement : id_auteur, nom et mail. (mais cet auteur ne doit en général pas être confondu avec l’internaute sessionné ayant généré un cache)
  • tous les invalideurs (dont les invalideurs génériques : cache et session)
  • seulement les invalideurs spécifiques à ce squelette, s’il y en a.
  • la liste des noisettes inclues dynamiquement avec <INCLURE...> dans ce squelette

Lorsqu’un élément du contexte affiché est un identificateur d’objet SPIP, alors un bouton apparaît à droite : ce bouton mène à la page SPIP d’édition de cet objet. Au survol de la souris sur ce bouton, un hint indique le titre SPIP de l’objet.

Rq : comme l’affichage des informations ’extra’ pour chaque élément de la liste nécessite la consultation du cache, elle incrémente le nombre de ’hit’ sur ce cache, qui en plus de compter les hits nécessités par votre jeu de squelette, va également compter le nombre d’affichages extra faits avec xray. Autrement dit : comme en physique quantique, l’observation modifie le phénomène observé.

Si le plugin macrosession est installé et actif, ce menu propose aussi d’afficher
-  la liste des appels aux macros #_SESSION ou #_SESSION_SI. Il indique alors les arguments : le champ consulté et les éventuels opérateur et opérande.
-  la liste des appels aux macros #_AUTORISER_SI. Il indique alors les arguments de chaque appel.

Exemple : Dans un squelette admin_control.html, il y a un appel à #_AUTORISER_SI{webmestre} et un appel à #_AUTORISER{modifier, article, 2}. Lorsqu’on demande à voir les appels à #_AUTORISER, il apparaît ceci :

...8e7ccc6-admin_control/
[0] => 'webmestre'
[1] => 'modifier', 'article', '2'

Filtrage

On peut faire une recherche sur les noms des caches, et ne plus lister, par exemple, que les caches des squelettes content/article_resume.

Un menu déroulant permet de demander à ne voir

  • que les caches des squelettes non sessionnés
  • que les caches des squelettes sessionnés
  • que les caches des squelettes sessionnés de visiteurs identifiés
  • que les caches des squelettes sessionnés de visiteurs non identifiés
  • que les « talons » de sessions (qui ne servent que de repère, mais sont pratiques pour accéder à tous les caches sessionnés correspondant à un même squelette dans un même environnement donné)
  • que les caches de formulaire
Liste, filtrage et détails des caches
Dans cette configuration, seuls les caches sessionnés sont affichés. Ici, ce sont uniquement les caches sessionnés de visiteurs non identifiés.
On a demandé à voir les éléments de contextes spécifiques.

Un autre menu déroulant permet de faire cette recherche non sur les noms des caches mais sur leur contenu.
4 options sont proposées pour faire la recherche :

  • dans les noms des caches. Cela permet de cibler les caches d’un squelette particulier. C’est le fonctionnement par défaut et cela suffit pour la plupart des situations basiques. Ce mode ne modifie pas le nombre de hits des caches.
  • dans le contenu des caches. Pour une recherche tout azimut dans le HTML produit, dans le contexte et les autres métadonnées.
  • dans le HTML mis en cache seulement
  • dans les métadonnées seulement : contextes, invalideurs et autres.
  • dans le contexte seulement : les variables d’environnement reçues par le squelette, au format « print_r » : [nom variable] => valeur.

Zoom sur un cache

Quand on zoom sur un cache, sa valeur est présentée désérialisée lorsque c’est possible, sous la forme du source du tableau php. On distingue ainsi nettement les différentes métadonnées (contextes, invalideurs et autres) et le squelette HTML.

Un bouton local et un menu déroulant général permettent de demander à voir tout le HTML ou à ne voir que le début du HTML (80 premiers caractères) lorsque ce n’est pas cela qui nous intéresse.

Lorsqu’une entrée des métadonnées correspond à un identifiant d’objet SPIP, un lien permet d’accéder à sa page d’édition.
Par ailleurs, les 2 entrées source et squelette, dont les valeurs affichées sont, respectivement, l’adresse du fichier squelette source et du fichier squelette compilé, sont cliquables et donnent accès à la visualisation de ces sources, dans un nouvel onglet du navigateur.

Les caches des textwheels ne sont pas désérialisées.

Marqueur invisible pour révéler les informations de session

XRay donne à voir les sessions, la liste des caches sessionnés pour une même session, mais n’indique pas à quel internaute correspondent ces informations. Parfois, on a besoin de ces informations pour comprendre « ce qui se passe ».
Pour cela, le plugin XRay est livré avec une noisette inclure/xray_cache_invisible qui donne un aperçu des données d’une session : id_auteur, nom et email et que vous pouvez surcharger dans votre dossier squelette pour la personnaliser en ajoutant ou retranchant des informations.
Cette noisette est invisible, c’est à dire que lorsqu’elle est inclue dans un squelette, rien est ajouté au HTML généré, mais cette information permet de capturer dans la session les informations voulues et de les copier dans les caches d’une noisette xray_marqueur_visible. Cette noisette n’est inclue nulle part dans le squelette et ne sera jamais rendue sur le site public, mais son contenu sera visible dans XRay.

Vous devez donc inclure la noisette invisible dans un de vos squelettes (par exemple le footer) :

<INCLURE{fond=inclure/xray_marqueur_invisible}

, et les informations de sessions apparaitront avec XRay, dans les caches de la noisette visibles.

De plus, si vous avez activé CacheLab, les boutos donnant accés à tous les caches d’une même session présenteront au survol le contenu de ce marqueur invisible.

Page de stats générales

En plus des statistiques, des paramètres et des graphiques de fragmentation et de répartition des caches d’APC, un nouvel encart dédié à SPIP apparaît.
Il présente
-  la valeur du préfixe de nom des caches : _CACHE_NAMESPACE. utilisé par memoization.
-  des statistiques : nombre de caches, volume mémoire, date de création du plus vieux cache, nombre de requêtes, nombre de hits, rendement du cache. Le rendement du cache est le ratio de hit pondéré par le volume mémoire de chaque cache.

Ces statistiques sont présentées :
-  pour tous les caches.
-  pour les javascripts et css seulement. Il est possible de personnaliser l’expression régulière qui détecte ces caches, afin de cibler les squelettes de votre choix, via un define dans votre fichier d’option (voir xray_options.php).
-  pour les autres caches actifs.
-  pour les caches présents en mémoire mais invalidés par SPIP. La date d’invalidation générale est également indiquée, ainsi que la date d’invalidation des caches consécutifs à une mise à jour de la table de votre choix. Par défaut, ce sont les articles mais vous pouvez choisir via un define dans votre fichier d’option (voir xray_options.php).
-  pour les caches encore référencés par APC, mais périmés. Un certain nombre de cache récemment périmés reste en effet indexé, quand bien même leur espace mémoire a été libéré.

Après une purge du cache, les rendements des caches sont tous de 0 puisqu’il faut recréer tous les caches. Avec le temps et les visites sur le site, ces rendements augmentent.
-  Après quelque temps, le rendement des caches js et css peut avoisiner les 100%. Sinon, c’est a priori que vous utilisez mal les outils spip pour l’insertion du javascript et des css.
-  Le rendement des caches html augmente aussi mais il plafonne à moins de 100%, à une valeur dépendant de la structure du site. Si vous employez beaucoup les balises #SESSION ou #AUTORISER, il y aura beaucoup de cache sessionnés, qui ne servent que pour un seul visiteur et qui ne sont donc pas ou peu réemployés : le rendement sera moins bon. Pour limiter ces effets, voyez les conseils de l’article Utilisation de la balise #SESSION et optimisation et éventuellement le plugin macrosession.

Utilisation pour le debug et l’optimisation

XRay est un bon moyen pour mieux se rendre compte du fonctionnement du cache, des enjeux de sa bonne gestion et des stratégies d’optimisation :
-  SPIP, PHP et Javascript sont dans un bateau
-  Utilisation de la balise #SESSION et optimisation
-  Optimiser les performances de SPIP
-  Du php dans le squelette à la place de #SESSION ou #CACHE 0

À partir de cette compréhension, la liste les caches sessionnés permet de passer en revue le cache et son usage à bon ou mauvais escient. C’est un bon complément à au plugin macrosession. Si un cache est sessionné alors qu’il ne devrait pas l’être, on peut étudier son cas et corriger cela. On peut ainsi lutter contre la multiplication des caches sessionnés qui mine l’efficacité du cache ; orienter la démarche d’optimisation vers certains squelettes et vérifier l’impact des optimisations réalisées.

Avoir un accès rapide et facile au contexte des caches permet également de débusquer des bugs :
-  arguments inutiles pour des inclusions.
-  mauvaise valeur d’arguments
-  appels à des inclusions avec des arguments

{env}

superflus (et donc nuisibles)
-  squelettes appelés de manière sessionnée et non sessionnée à la fois (selon l’endroit)
-  coexistence d’appels en http et en https: selon que c’est en http ou https, le préfixe du nom de cache est différent, ce qui se voit très bien et doit vous alerter sur le fait que les redirections ne se font pas parfaitement.

L’activation de xray n’interfère aucunement sur le fonctionnement du site. Néanmoins, une fois terminé le travail d’observation ou d’optimisation des squelettes, xray devient inutile. On peut le désactiver et il peut ensuite être réactivé à tout moment.

Remarques :
-  Le plugin s’appuie sur des heuristiques pour filtrer les caches selon leur type (sessionné ou non, visiteur identifié ou non). Il n’est pas exclu que certains cas particuliers soient mal filtrés et qu’il faudra affiner. Vos retours sont bienvenus.
-  XRay fonctionne uniquement avec APC et APCu Cache. Il serait utile de développer aussi une version pour memcached, XCache et redis. Une version filecache risque d’être franchement lente, mais serait peut être utile, même sans réactivité. En attendant, si votre hébergement permet d’activer APC Cache, ça vaut le coup de le faire même temporairement, le temps d’utiliser xray et d’examiner le cache.

Voir  :
-  Complément XRay
-  Retours sur l’usage de Xray et CacheLab

Discussion

3 discussions

Ajouter un commentaire

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom

Dernière modification de cette page le 9 décembre 2018