期待量化在python django应用程序中NewRelic监控的性能开销 [英] Looking to quantify the performance overhead of NewRelic monitoring in python django app
问题描述
我正在一个包含多个应用服务器，MySQL服务器等的大型Django（v1.5.1）应用程序。在将NewRelic推送到所有服务器之前，我想了解我将会承担什么样的开销交易。
如果可能，我甚至可以区分应用程序跟踪和服务器监控，这将是理想的。
$ b $有没有人知道这个普遍接受的数字？也许一个网站正在进行这种调查或步骤，以便我们可以自己进行调查。
对于Python代理和Django Web应用程序的监控，每个请求的开销是由被调用的特定请求中执行的功能数量所驱动的。这是因为完整的分析没有完成。相反，只有具体的兴趣职能才被检测。因此，只有为一个函数调用执行包装器的开销，而不是嵌套调用，除非这些嵌套函数反过来被调用。
在Django中测试的具体功能是中间件和视图处理函数，以及模板渲染以及模板渲染器中处理每个模板块的功能。您可以使用Django本身的低级数据库客户端模块功能来执行查询，以及memcache和web externals等。
这意味着如果一个特定的Web请求执行只通过100个仪器功能，那么这只是执行额外开销的那些。如果相反，您的视图处理程序执行了大量不同的数据库查询，或者您有一个非常复杂的模板被渲染，则检测函数的数量可能会更多，因此该Web请求的开销将更多。也就是说，如果您的视图处理程序正在进行更多的工作，那么通常它的响应时间通常比较复杂的要长。
换句话说，每个请求开销并不固定，并且取决于要完成多少工作，或者更具体地调用多少被调用函数。因此，不可能量化事情，并给您一个固定的每个请求数额的开销。
这一切都说会有一些开销，一般目标范围是目标是大约5％。
通常情况下，通过获得性能指标获得的洞察意味着对于大多数客户来说通常会有一些非常简单的改进几乎可以立即找到。做出这样的改变后，响应时间可以很快被降低到低于开始监视之前的时间，所以当你没有监视时，你最终会超前于你要开始的地方。随着进一步挖掘和调整，改进可以更加戏剧化。注意提供的性能指标的某些方面，您还可以更好地调整WSGI服务器，或者更好地利用它，并减少所需的主机数量，从而降低主机成本。
I am working on a large Django (v1.5.1) application that includes multiple application servers, MySQL servers etc. Before rolling out NewRelic onto all of the servers I want to have an idea of what kind of overhead I will incur per transaction.
If possible I'd like to even distinguish between the application tracking and the server monitoring that would be ideal.
Does anyone know of generally accepted numbers for this? Perhaps a site that is doing this sort of investigation or steps so that we can do the investigation on our own.
For the Python agent and monitoring of a Django web application, the overhead per request is driven by how many functions are executed within a specific request that are instrumented. This is because full profiling is not being done. Instead only specific functions of interest are instrumented. It is therefore only the overhead of having a wrapper being executed for that one function call, not nested calls, unless those nested functions were in turn ones which were being instrumented.
Specific functions which are instrumented in Django are the middleware and view handler function, plus template rendering and the function within the template renderer which deals with each template block. Distinct from Django itself, you have instrumentation on the low level database client module functions for executing a query, plus memcache and web externals etc.
What this means is that if for a specific web request execution only passed through 100 instrumented functions, then it is only the execution of those which incur an extra overhead. If instead your view handler performed a large number of distinct database queries, or you have a very complicated template being rendered, the number of instrumented functions could be a lot more and as such the overhead for that web request will be more. That said, if your view handler is doing more work, then it already would generally have a longer response time than a less complex one.
In other words, the per request overhead is not fixed and depends on how much work is being done, or more specifically how many instrumented functions are invoked. It is not therefore possible to quantify things and give you a fixed per request figure for the overhead.
That all said, there will be some overhead and the general target range being aimed at is around 5%.
What generally happens though is that the insight which is gained from having the performance metrics means that for most customers there are usually some quite easy improvements that can be found almost immediately. Having made such changes, response times can quite quickly be brought down to be below what they were before you started monitoring, so you end up being ahead of where you were to start with when you had no monitoring. With further digging and tuning, improvements can be even much more dramatic. Pay attention to certain aspect of the performance metrics being provided and you can also better tune your WSGI server and perhaps better utilise it and reduce the number of hosts required and so reduce your hosting costs.
这篇关于期待量化在python django应用程序中NewRelic监控的性能开销的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
