¿Cómo perfilarías un servicio Python que se volvió más lento tras una release?

Empieza acotando adónde se va el tiempo antes de tocar código. Compara el diff de la release, mira el tracing o las métricas de tiempos para encontrar el endpoint lento, y luego perfila esa ruta con cProfile o py-spy, que puede muestrear un proceso vivo sin reiniciarlo. Fíjate en el tiempo acumulado para encontrar la llamada responsable, formula una hipótesis, cambia una cosa y vuelve a medir.

La primera pregunta es qué cambió en realidad, porque una release me da una lista corta de sospechosos. Luego quiero números y no opiniones, así que los spans de tracing o los tiempos por endpoint me dicen qué ruta se degradó y si el tiempo está en la base de datos, en una llamada externa o en el propio proceso. Si está en el proceso, py-spy es lo primero a lo que recurro porque se engancha a un contenedor en marcha y muestrea sin reiniciar, así que puedo perfilar la carga real de producción y no una sintética. Un flame graph suele dejarlo obvio. Para un caso local reproducible uso cProfile y ordeno por tiempo acumulado, porque el tiempo propio esconde a quien llama, que es el verdadero responsable. Una precaución: perfilar cambia los tiempos, así que nunca me fío de sus números absolutos, solo de la forma relativa. Después cambio exactamente una cosa y vuelvo a medir. La última vez que hice esto el culpable era un serializador nuevo que hacía una copia profunda por fila, y quitar esa copia devolvió el endpoint de cuatrocientos milisegundos a noventa.