Carnet Wiki

Complément et todo XRay

Todo

  • DEV stats globales sur les sessions et le sessionnement, sur les squelettes et les talons :
    - nombre de sessions total, nombre total de squelette
    - nombre de sessions par talon
    - nombre de caches par squelette
    - nombre de talon par squelette
  • REBOOT : refaire tout avec les méthodes de Memoization (le code APCu utilisé à la base date de 1983 environ) et d’autres méthodes ajoutées (un itérateur notamment). En profiter pour fonctionner même si ya une clé de cryptage du cache. Ajouter une méthode List à Memoization pour finir l’abstraction du code PUIS définir cette méthode pour les autres modes de mémoization, en tenant compte du CACHE_NAMESPACE et, au passage, permettre de gérer des sous-listes.
  • ANALYSE : quel est le nommage des caches des squelettes appelés comme page ? parfois c’est chemin_squelette/ parfois c’est chemin_squelette/12354 parfois c’est chemin_squelette/spip.
    Pourquoi toutes ces variations ?
    Voir generer_nom_fichier_cache dans memoization/public/cacher : ça vient de $page['contexte_implicite']['cache']. Toutes les pages appelées directement y sont elles ? Y a t il du coup 2 caches (identiques ?) : l’un pour l’appel via ?page= et l’autre (sans suffixe /spip) pour l’appel via INCLURE ?
  • ANALYSE : qu’est il possible de faire pour les squelettes issus de styliser ? Peut on les reconnaître ?
  • DEV : Filtrages par « type de cache » : ajouter « pages » si possible, « compositions » (source != nom), « HTML statique » et « Avec PHP » (’process_ins’), « http », « https », « aliens », « vide », « périmé », « not_array ».
  • DEV : chercher dans ’source’ (utile pour les compositions), ’entetes’.
  • DEV : dans les choix d’affichages extra, ajouter #PRODUIRE (« produire_fond_statique »)
  • Depuis quelques releases, l’algorythme de sélection des caches affichés a été désoptimisé pour simplifier le code, et depuis, chaque affichage de la page xray lit tous les caches et incrémente donc les hits. On pourrait éviter et ne lire le contenu que si nécessaire ?
  • DEV : pour afficher les squelettes à partir de XRay, il faut récupérer leur adresse absolue et pour cela, avec find_in_path, il faut que le $GLOBALS['dossier_squelettes'] soit celui du public alors que XRay est appelé dans le privé. Il faut donc changer cette variable si possible juste le temps de faire la recherche du chemin des squelettes. Créer une fonction pour ça : sauvegarder $GLOBALS['dossier_squelettes'], récupérer les chemins publics déclarés par paquet.xml et modifier le $GLOBALS['dossier_squelettes'], appeler find_in_path puis restaurer sa sauvegarde.
    Hmm c’est tout de mm rare. On peut aussi plus roots demander à forcer le dossier squelette si ?exec==xray par un petit ajout dans le mes_options.
  • DEV : ajouter boutons-liens à droite :
    -  boutonlien « session » sur la ligne session dans les invalideurs
    -  boutonlien « mm squel » sur la ligne du squelette d’un contenu détaillé + sur les talons ?
    -  boutons_lien sur les id_xxx des zooms comme dans le contexte
  • DEV : Améliorer le lien avec Cachelab. Déjà il y a le bouton ’Del’. NOW remplacer ’Go’ par ’List’. On bénéficiera aussitôt de la destruction des caches « périmés SPIP » ou qui n’existent plus pour APC même s’ils sont encore listés
  • FIX : Supprimer colonne « Dernier accès » puisque XRay y accède et foire cette donnée. Ou ya mieux à faire ?
  • DEV : valeurs corrigées des hits : « avant », les caches étaient filtrés par leur nom seulement, et le contenu n’était accédé que si on demandait à voir leur contenu. Depuis la détection des talons et les boutons « mm talon », le code a été allégé mais le contenu des caches est désormais accédé à chaque rafraîchissement de la liste, même s’il n’y en a pas besoin. Du coup, la consultation de xray fait vite monter le taux de hit... sans que ça reflète une meilleure gestion du cache pour le site public. Il serait possible de restituer une vision fidèle des hits et du taux de cache :
    - a) tenir dans un cache global durable (APC) la chronologie des lectures techniques (dûes à XRay ou CacheLab) depuis le dernier vidage des caches : une liste de datetime.
    - b) lors des affichages et calculs de taux de hits à l’instant t, on peut calculer le véritable nombre de hits pour les besoins du site : N(nombre total de hits du cache à t) - N(raffraichissements techiques depuis la date de création du cache) .
  • ANALYSER : Le talon des caches sessionnés d’un squelette occupe le même espace (index de cache) que le cache non sessionné de ce squelette (pas de suffixe _). Or ils ne sont pas du tout identiques. Une fois le talon créé, c’est le cache sessionné sans auth (avec suffixe _$) qui sera également utilisé par la suite en guise de cache non sessionné donc pas de pb dans cet ordre là. Vérifier comment ça se passe si c’est le cache non sessionné qui est créé d’abord.
JLuc - Mise à jour :5 juin 2022 à 00h03min