XRay, un explorateur des caches SPIP

Browser des caches APCu : tout voir et tout savoir sur les caches spip, les trier, les sélectionner, les invalider sélectivement, comprendre la compilation du code spip, débuguer et optimiser les squelettes.

Ce plugin est construit à partir du browser de cache APCu. 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 ou APCu. Il intègre par ailleurs une petite page d’essai de ’CacheLab’, l’invalideur sélectif de caches.

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 ou APCu et vous devez avoir installé et activé le plugin memoization avec APC ou APCu
-  Vous devez avoir define('_CACHE_KEY', ''); dans votre mes_options.php (ce qui signifie que les caches ne sont pas cryptés) — au moins le temps de votre analyse, car une fois votre analyse faite, vous pouvez restaurer une valeur de _CACHE_KEY si c’est utile sur votre hébergement.

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.

Une option « Cache | Squelettes » permet de basculer d’une liste de caches à une liste de squelettes. Bien entendu, chaque squelette a de nombreux caches associés.

Le temps de parcours global de la liste est indiqué.

Autres affichages ’extra’

Un menu déroulant permet d’afficher plus d’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 communs à tous les caches)
  • Le chemin et le nom du fichier squelette
  • 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 des squelettes utilisés comme page
  • que les caches des squelettes utilisés comme inclusion
  • 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 puisqu’on cherche dans le nom, et non dans le contenu. Il est possible d’utiliser les caractères spéciaux de la syntaxe des expressions régulières pour cette interrogation. Par exemple 404$</nom> ramènera les caches du squelettes <code>404.html
  • 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. Pour faciliter l’interrogation, il suffit de demander « variable=truc » pour obtenir tous les caches ayant cette variable et cette valeur dans leur environnement. [1]

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 et peut par exemple présenter la liste des caches sessionnés pour une même session. Mais basiquement il n’indique pas à quel internaute correspondent ces informations car il n’est pas possible de le savoir sans autre outil. Pourtant on a parfois besoin de ces informations pour comprendre « ce qui se passe ».

Le plugin XRay est donc livré avec un petit squelette inclure/xray_marqueur_session qui permet d’associer à une session les données de l’internaute correspondant : id_auteur, nom et email. Ce squelette doit être inclu dans vos squelettes, par exemple dans le footer.html.

Cette inclusion n’ajoute rien au HTML généré, mais elle capture les informations associées à la session courante, et les mémorise dans un cache xray_marqueur_sessions.

Par la suite, lorsque XRay présente les caches, il détecte ceux qui sont sessionnés et présente pour chacun d’eux un bouton qui donne sélectionne la liste de tous les caches sessionnés pour cette même session. Lorsque les informations de xray_marqueur_session sont disponibles, elles sont alors présentées lorsque la souris survole ce bouton.

Rq : Par défaut, cette inclusion mémorise l’id_auteur, le mail et le nom de la session, mais vous pouvez le surcharger dans votre dossier squelette pour ajouter ou retrancher des informations.

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.
-  le temps de parcours et d’interrogation de tous les caches. Cette information donne une indication du temps d’exécution d’un appel à cachelab_cibler, la fonction centrale au plugin cachelab.

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.

Notes

[1Remarque pouvant être ignorée : lorsque ce n’est pas au format variable=truc, on peut aussi parfois interroger (selon la version) avec les caractères spéciaux des regexp et en tenant compte du fait que le format profond interrogé est celui issu d’un print_r : [nom variable] => valeur.

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 aussi


-  Les enseignements de XRay
-  Complément et todo XRay
-  Archives : statistiques cachelab

Discussion

5 discussions

  • 3

    Salut,

    Super intéressant, je fais quelques essais et je trouve ce plugin vraiment extra !
    Le plugin nécessite la déclaration d’un define afin de pouvoir accéder à l’interface de Apcu

    # CACHE LAB
    define('_CACHE_KEY', '');

    Mais qui engendre une notice sur memoization :

    Notice: Constant _CACHE_KEY already defined in /var/www/spip/spip3.3-svn/sites/dist.loc/plugins/auto/memoization/v2.1.6/memoization_options.php on line 129

    lorsque je lis le code de memoization je ne comprends pas vraiment pourquoi il faut déclarer ce _CACHE_KEY ??

    • Hello Pierrox,

      Définir _CACHE_KEY est utile chez certains hébergeurs lorsque le cache APC est partagé entre différents clients différents ; ça sert à crypter les caches et ça permet qu’un webmaster ne puisse pas accéder aux caches (et donc aux données) des sites qui ne sont pas les siens.

      Chez un hébergeur où les caches APC ne sont pas mutualisés c’est totalement inutile. Pour éviter la notice, il faut le définir à ’’ dans ton mes_options.

    • Hum, Il y a eu une modif de memoization qui génère une notice et qui pète l’affichage des graphiques dans xray.

      https://zone.spip.net/trac/spip-zone/changeset/114180/spip-zone

    • Pas de pb ici. Ç’a du être réglé.

    Répondre à ce message

  • V0.21 il y a maintenant la possibilité de lister non les caches mais les squelettes. La recherche continue à se faire sur les caches, mais ce sont les squelettes des caches résultats qui sont affichés. Il y en a beaucoup moins puisque chaque squelette peut générer de nombreux caches.
    C’est trés pratique pour, par exemple, voir directement la liste des squelettes sessionnés et qu’on voudrait désessionner avec le plugin macrosession.

    Répondre à ce message

  • 1

    v0.12 : nouvelles stats de rendement du cache pour tous les caches ou pour les js et css seulement ou pour les autres seulement.

    • L’API CacheLab a été reportée dans le plugin CacheLab qui a bien avancé depuis.

      XRay se développe aussi tranquillement.
      Documenté ce jour : les marqueurs invisibles, qui permettent d’afficher dans XRay des informations sur chaque session afin de mieux comprendre ce qui se passe dans les caches sessionnés.

    Répondre à ce message

  • Le commit 108859 et les suivants implémentent les prémisses d’un API CacheLab 1. Action sur des caches ciblés.

    Répondre à ce message

  • Quand le cache SPIP est invalidé, les caches restent en mémoire APC, mais ne sont plus utilisés par SPIP. La version 0.13 présente les stats pour ces caches invalides, et ne les inclue pas dans les stats utiles globales.

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

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