Comment profileriez-vous un service Python devenu plus lent après une mise en production ?

Commencez par cerner où part le temps avant de toucher au code. Comparez le diff de la version, regardez le tracing ou les métriques de temps pour trouver l'endpoint lent, puis profilez ce chemin avec cProfile ou py-spy, qui peut échantillonner un processus vivant sans redémarrage. Regardez le temps cumulé pour trouver l'appel responsable, formulez une seule hypothèse, changez une seule chose, et mesurez à nouveau.

La première question est ce qui a réellement changé, parce qu'une mise en production me donne une courte liste de suspects. Ensuite je veux des chiffres, pas des avis, donc les spans de tracing ou les temps par endpoint me disent quelle route a régressé et si le temps est dans la base, dans un appel amont ou dans le processus lui-même. Si c'est dans le processus, py-spy est mon premier réflexe parce qu'il s'attache à un conteneur en cours et échantillonne sans redémarrage, ce qui me laisse profiler la vraie charge de production plutôt qu'une charge synthétique. Un flame graph rend en général la chose évidente. Pour un cas local reproductible j'utilise cProfile et je trie par temps cumulé, puisque le temps propre cache l'appelant réellement responsable. Une mise en garde : profiler modifie les temps, donc je ne fais jamais confiance aux valeurs absolues, seulement à la forme relative. Puis je change exactement une chose et je remesure. La dernière fois, le coupable était un nouveau sérialiseur qui faisait une copie profonde par ligne, et supprimer cette copie a ramené l'endpoint de quatre cents millisecondes à quatre-vingt-dix.