Buscando cuantificar la sobrecarga de rendimiento del monitoreo NewRelic en la aplicación Python Django

Estoy trabajando en una gran aplicación de Django (v1.5.1) que incluye múltiples servidores de aplicaciones, servidores MySQL, etc. Antes de implementar NewRelic en todos los servidores, quiero tener una idea del tipo de sobrecarga en la que incurriré por transacción.

Si es posible, me gustaría distinguir incluso entre el seguimiento de la aplicación y el monitoreo del servidor que sería ideal.

¿Alguien sabe de números generalmente aceptados para esto? Tal vez un sitio que esté haciendo este tipo de investigación o pasos para que podamos hacer la investigación por nuestra cuenta.

Para el agente de Python y la supervisión de una aplicación web de Django, la sobrecarga por solicitud se determina por la cantidad de funciones que se ejecutan dentro de una solicitud específica que se instrumentan. Esto es porque el perfil completo no se está haciendo. En su lugar, solo se instrumentan funciones específicas de interés. Por lo tanto, es solo la sobrecarga de tener un contenedor que se está ejecutando para esa llamada de función, no llamadas anidadas, a menos que esas funciones anidadas fueran a su vez las que se estaban instrumentando.

Las funciones específicas que se instrumentan en Django son la función de middleware y controlador de vista, más la representación de plantillas y la función dentro del procesador de plantillas que se ocupa de cada bloque de plantillas. A diferencia del propio Django, tiene instrumentación en las funciones del módulo de cliente de base de datos de bajo nivel para ejecutar una consulta, además de memcache y web externos, etc.

Lo que esto significa es que si para una solicitud web específica la ejecución solo pasara a través de 100 funciones instrumentadas, entonces es solo la ejecución de aquellas que incurren en una sobrecarga adicional. Si, en cambio, su controlador de vista realizó una gran cantidad de consultas de bases de datos distintas, o si tiene una plantilla muy compleja que se está procesando, la cantidad de funciones instrumentadas podría ser mucho mayor y, como tal, la sobrecarga de esa solicitud web será mayor. Dicho esto, si su controlador de vista está haciendo más trabajo, entonces generalmente tendrá un tiempo de respuesta más largo que uno menos complejo.

En otras palabras, la sobrecarga por solicitud no es fija y depende de la cantidad de trabajo que se está realizando o, más específicamente, de cuántas funciones instrumentadas se invocan. Por lo tanto, no es posible cuantificar las cosas y darle una cifra fija por solicitud para la sobrecarga.

Dicho todo esto, habrá algunos gastos generales y el rango objective general que se pretende alcanzar es de alrededor del 5%.

Sin embargo, lo que generalmente ocurre es que la información que se obtiene al tener las métricas de rendimiento significa que para la mayoría de los clientes generalmente hay algunas mejoras bastante fáciles que se pueden encontrar casi de inmediato. Una vez realizados tales cambios, los tiempos de respuesta pueden reducirse rápidamente a estar por debajo de lo que eran antes de que comenzara a monitorear, por lo que terminará por delante de donde estaba cuando no tenía monitoreo. Con más excavaciones y ajustes, las mejoras pueden ser incluso más dramáticas. Preste atención a ciertos aspectos de las métricas de rendimiento que se proporcionan y también puede ajustar mejor su servidor WSGI y quizás utilizarlo mejor y reducir la cantidad de hosts necesarios y así reducir sus costos de alojamiento.