Trace 2 - Profiler de la chaîne d'export Cockpit

Trace 2

Profiler pour rendre les lenteurs visibles

Agrandir

La Trace 2 ci-contre est une capture réelle du fichier profiler.log. Elle montre deux exports du même rapport Cockpit : un export avec

OpenTBS, puis un export avec OpenSpout. Les zones entourées en bleu mettent en évidence les deux informations les plus importantes pour comparer les exécutions : le moteur utilisé et le temps total du run.

1. Chaque bloc possède un identifiant export-..., ce qui permet de suivre une exécution complète.
2. Le contexte précise le nom du fichier et le moteur d'export, donc la comparaison reste lisible.
3. Les étapes détaillent la planification, l'envoi des lots, la génération et le résultat final.

Extrait représentatif du log utilisé dans la Trace 2 :

Contexte: nomFichier: uap_report_FR2...xlsm, moteur: opentbs
[api-local] export.défaut: 490.78 s
Total: 494.67 s
Statut: terminé

Contexte: nomFichier: uap_report_FR2...xlsx, moteur: openspout
[api-local] export.défaut: 5.83 s
Total: 10.21 s
Statut: terminé

Avant la Trace 2, le problème était formulé de façon trop vague : l'export était long, parfois fragile, et il était difficile de savoir quelle partie de la chaîne provoquait le ralentissement. Le profiler visible dans la Trace 2 a transformé ce constat en mesures exploitables. Le savoir-faire instrumenter une chaîne complète avant d'optimiser se retrouve dans le découpage des étapes : création du job, planification des lots, upload, génération du fichier et statut final.

Grâce à l'identifiant du run et aux durées associées dans la Trace 2, je pouvais aussi

organiser une investigation technique sans mélanger les résultats de plusieurs essais. Cela m'a permis d'avancer par hypothèses : vérifier le moteur Excel, tester l'envoi par lots, observer le temps côté API PHP, puis valider que la nouvelle génération OpenSpout réduisait réellement le temps total.