Trace 2 - Profiler de la chaine d'export Cockpit

Trace 2

Profiler pour comprendre les lenteurs

Agrandir

Cette trace montre le profiler ajoute sur la chaine de recherche et d'export Cockpit. Au depart, les lenteurs etaient visibles pour l'utilisateur, mais il etait difficile de savoir si elles venaient de MongoDB, du frontend, de PHP, du moteur Excel ou de l'ecriture fichier.

1. Chaque run possede un identifiant unique, par exemple export-..., pour relier les logs frontend et backend.
2. Les etapes sont nommees : plan-batches, upload-batches, start-generation, save-file, generate-file.
3. Les logs indiquent aussi le contexte : moteur utilise, nombre de batches, lignes envoyees, taille payload et taille du fichier.

Ce que le profiler a permis d'identifier

Avant le profiler, j'avais seulement des erreurs ou des impressions : export long, crash memoire, payload trop gros. Avec les mesures, j'ai pu separer plusieurs problemes :

• la recherche MongoDB pouvait etre lente sans index adaptes ;
• OpenTBS passait beaucoup de temps a charger et sauvegarder le template Excel ;
• l'envoi d'un payload complet risquait de depasser post_max_size ;
• certains jobs restaient dans un etat peu clair quand une erreur arrivait pendant l'envoi.

Analyse des savoir-faire

Le savoir-faire principal est instrumenter une chaine complete. J'ai place les mesures a plusieurs niveaux au lieu de mesurer seulement le temps final. Cela permet de savoir quelle partie corriger en priorite.

J'ai aussi travaille l'organisation d'une investigation technique. Le profiler a servi de support de decision : apres chaque modification, je pouvais relancer un export et verifier si le gain venait vraiment du changement effectue.

Cette trace est importante car elle transforme un probleme flou en liste d'actions testables. C'est aussi ce qui m'a permis de produire des tableaux de benchmark et des schemas fiables pour l'equipe.