Carnet Wiki

Debug & Profilage

Version 10 — Avril 2018 — 194.177.xx.xx

Explorer l’amélioration de l’outil de debug et notamment de profilage dans spip
-  Constats
-  Pistes « locales »

Constat2

var_mode=debug et var_profile=1 ou &var_mode=recalcul&var_profile=mysql donnent accés à de forts utiles informations pour qui veut allége alléger l’impact environnemental de son site spip

<blockquote class="spip">

Sur le debug en général, on lira les excellents tutoriaux vidéos de Cédric :
-  pour débuter : http://videos.spip.org/spip.php?art...
-  pour aller loin : http://videos.spip.org/spip.php?art...

</blockquote>

On y apprend combien de temps nécessite la compilation et le calcul de chaque noisette, inclusion ou élément de spip (boucle notamment) d’une page donnée - et donc d’un squelette précis- .

Il manque toutefois la prise en compte de l’effet des caches : impossible actuellement de savoir combien de fois le recalcul d’une inclusion ou d’un élément est réellement effectué.

Or le temps réellement passé sur un élément spip au cours d’une journée dépend évidemment du temps unitaire passé sur une occurence de compilation et de calcul, mais aussi de la fréquence de mise à jour du calcul, laquelle dépend, sur un site pleinement fréquenté, de la durée du cache de cet élément.

Temps réel = Temps unitaire x Nombre de calculs
TR = TU x NC

Le debugueur indique non seulement le temps de calcul, mais aussi le temps de compilation (du moins lors d’un var_mode=recalcul). Toutefois, dans une utilisation normale du site, la compilation n’a lieu qu’une seule fois. Il me semble donc qu’on peut abandonner cette étape.

Il manque donc un outil qui donne les temps réels cumulés d’exécution sur une journée, par exemple, de l’ensemble des boucles et inclusions de spip, une par une.

Etant donné le cout probable en temps d’exécution de collecte et traitement de ces informations de debug, il sera nécessaire de ne l’activer que sur une période donnée : définition d’une durée d’étude (1 heure de grande fréquentation, ou 1 jour par exemple) et de donner un top départ : à partir de ce moment et pendant la durée définie, les données sont collectées. Quand c’est fini, plus de collecte, mais exploitation / visualisation possible des résultats synthétiques (temps réels cumulés des différentes unités).

Pour cela, plusieurs approches :

-  1) enregistrer des logs à un format standard et utiliser un outil libre de profilage pour les exploiter. Les plus exigeants des utilisateurs auront alors accés à une multitude d’informations pointues leur permettant d’optimiser au mieux leur code en mettant en oeuvre des compétences spécifiques.

-  2) enregistrer des logs minimaux ne contenant que les informations directement utiles, et en visualiser la synthèse au sein des pages existantes du debugueur actuel. Les utilisateurs auront alors les informations leur permettant de savoir immédiatement à quelle boucle ou inclusion s’attaquer le plus efficacement.

Notes en Vrac pour faciliter le debugging

php.ini
Options à mettre dans mes_options.php

error_reporting(E_ALL); ini_set ("display_errors", "On");
define('SPIP_ERREUR_REPORT', E_ALL);
define('SPIP_ERREUR_REPORT_INCLUDE_PLUGINS', E_ALL); 

Supprimer le cache

-  Vider le cache de SPIP : actionner le bouton dans la partie privée +
vider le répertoire /tmp et éventuellement /local/css-cache

-  Désactiver carrément le cache de SPIP : ajouter dans config/mes_options.php

define('_NO_CACHE',1);

On peut aussi le faire avec les plugins couteau_suisse ou couteau_kiss

-  Désactiver le cache du navigateur : mettre Firefox en mode « sans cache » avec le plugin webdevelopper

Avoir plus d’info SPIP pour le debugging :

Activer les rapports d’erreurs dans config/mes_options.php

error_reporting(E_ALL^E_NOTICE);
ini_set ("display_errors", "On");
define('SPIP_ERREUR_REPORT',E_ALL^E_NOTICE);
define('SPIP_ERREUR_REPORT_INCLUDE_PLUGINS',E_ALL^E_NOTICE);