Wie würdest du einen Python-Service profilen, der nach einem Release langsamer wurde?

Grenz erst ein, wo die Zeit hingeht, bevor du Code anfasst. Vergleich das Release-Diff, schau in Tracing oder Timing-Metriken, um den langsamen Endpunkt zu finden, und profile dann diesen Pfad mit cProfile oder py-spy, das einen laufenden Prozess ohne Neustart samplen kann. Achte auf kumulative Zeit, um den verantwortlichen Aufruf zu finden, bilde eine Hypothese, ändere eine Sache und miss erneut.

Erste Frage ist, was sich tatsächlich geändert hat, denn ein Release gibt mir eine kurze Verdächtigenliste. Dann will ich Zahlen und keine Meinungen, also sagen mir Tracing-Spans oder Timing pro Endpunkt, welche Route regressiert ist und ob die Zeit in der Datenbank, in einem Upstream-Aufruf oder im Prozess selbst steckt. Steckt sie im Prozess, greife ich zuerst zu py-spy, weil es sich an einen laufenden Container hängt und ohne Neustart sampelt, sodass ich die echte Produktionslast profile und keine synthetische. Ein Flame Graph macht es meist offensichtlich. Für einen reproduzierbaren lokalen Fall nehme ich cProfile und sortiere nach kumulativer Zeit, denn Self Time versteckt den Aufrufer, der wirklich verantwortlich ist. Eine Warnung: Profiling verändert das Timing, ich traue also nie den absoluten Zahlen daraus, nur der relativen Form. Dann ändere ich exakt eine Sache und messe erneut. Beim letzten Mal war der Übeltäter ein neuer Serializer, der pro Zeile eine Deep Copy gemacht hat, und das Entfernen dieser Kopie hat den Endpunkt von vierhundert Millisekunden zurück auf neunzig gebracht.