es.davy.ai

Preguntas y respuestas de programación confiables

¿Tienes una pregunta?

Si tienes alguna pregunta, puedes hacerla a continuación o ingresar lo que estás buscando.

Cómo interpretar los resultados de perfilado de py-spy del servidor web Tornado?

19 Jul, 2023 Programación

Estoy tratando de perfilar un servidor web tornado en ejecución dentro de un contenedor de Docker utilizando py-spy.

Usé las instrucciones en https://github.com/benfred/py-spy para configurar el flujo de trabajo de perfilado y parece funcionar y dar resultados, pero me cuesta entender lo que está sucediendo, ya que dos procesos parecen tener una contribución abrumadoramente grande, pero no están relacionados con el resto del servicio en el diagrama de llama.

Poner carga en el servidor y mirar el comando top de esta manera docker-compose -f docker-compose.profile.yml run pyspy top --pid 10621 --subprocesses --full-filenames da las siguientes principales contribuciones:

  %Propio   %Total  TiempoPropio  TiempoTotal  Función (nombrearchivo)
1600.00% 1600.00%   249.4s    249.4s   _run (/usr/local/lib/python3.8/site-packages/pymongo/periodic_executor.py)
1553.00% 1600.00%   244.9s    249.4s   _worker (/usr/local/lib/python3.8/concurrent/futures/thread.py)
23.00%  23.00%    2.57s     2.57s   read (/usr/local/lib/python3.8/ssl.py)
...

El diagrama de llama se ve así:

flamegraph

Como puede ver, la contribución de otros procesos es casi insignificante. Mi pregunta es cómo interpretar estos resultados. ¿Es el uso real o un artefacto de la programación asíncrona (que es una gran parte del código) que se muestren las partes del código que manejan las llamadas asíncronas?

Tags:  , , ,

Answer

  1. Avatar for davy.ai
    davy.ai

    Parece que estás perfilando un servidor web Tornado que se ejecuta en un contenedor de Docker usando py-spy, y estás teniendo dificultades para entender los resultados del perfilado. Las principales contribuciones muestran que dos procesos, _run y _worker, tienen una contribución abrumadoramente grande, pero no están relacionados con el resto del servicio en el flamegraph.

    Según los resultados, es posible que las contribuciones de _run y _worker estén relacionadas con el uso real del código, en lugar de ser un artefacto de la programación asíncrona en Tornado.

    Sin embargo, también es posible que las contribuciones de estos dos procesos se deban a la forma en que se gestionan las llamadas asíncronas en el código. Sin un análisis más profundo, es difícil determinar la causa exacta de sus contribuciones.

    Para interpretar estos resultados, es posible que desees profundizar en el código e intentar comprender las funciones y operaciones que se están ejecutando en _run y _worker. También puede ser útil comparar los resultados del perfilado con el rendimiento real del servidor web Tornado bajo carga para ver si hay alguna discrepancia o problema significativo.

Comments are closed.