Sub*_*der 7 python apache django mod-wsgi newrelic
项目部署为:django with apache mod_wsgi
获得配置为跟踪Web性能的新Relic lite版本.
在New Relic - > Monitoring - > Web transactions面板 - > Sort on最耗时 - >选择第一个条目 - > Breakdown Table - > WSGI/Response似乎消耗了81%的时间
Gra*_*ton 12
考虑一个简单的WSGI hello world程序.
def application(environ, start_response):
status = '200 OK'
output = 'Hello World!'
response_headers = [('Content-type', 'text/plain'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)
return [output]
从WSGI服务器的角度来看,让WSGI应用程序处理请求有两个关键阶段.
第一个是调用实际的WSGI应用程序,并返回结果.
第二个是WSGI服务器使用结果的行为,其结果是需要某种形式的可迭代产生字符串.
在New Relic下,"WSGI/Application"跟踪第一阶段所花费的时间.'WSGI/Response'正在跟踪第二阶段以及从返回的iterable中消耗字符串所花费的时间.
要理解为什么'WSGI/Response'可能会显示大量的时间,有必要更深入地了解实际情况.
第一个非常明显的事情是,在从iterable中产生每个字符串之后,WSGI服务器必须将该字符串写回发出请求的HTTP客户端.它不需要等到客户端收到它,但它确实需要做足够的工作以确保在从迭代中获取下一个字符串后,交付将继续并行.
因此,'WSGI/Response'记录的时间不仅包括从WSGI应用程序返回的迭代中产生每个项目所花费的时间,而且还包括将响应写回HTTP客户端所花费的时间.
因为它包括回写回复所花费的时间,所以可能会出现一些问题.
这些是非常大的响应可能需要时间来回写.如果底层Web服务器在任何时候阻塞,那么慢速客户端或网络可以使时间更长.最后,如果WSGI应用程序产生大量小字符串而不是单个字符串,或者至少产生较少数量的较大字符串,那么它本身就会变得更糟.
最糟糕的情况是WSGI应用程序,它有一个错误,它返回一个字符串对象作为结果,而不是产生字符串的列表或iterable.这很糟糕,因为字符串中的每个单个字符将一次写入一个,并发生相应的刷新以将其写回客户端.这可能导致过多的开销并增加所花费的时间.
如果使用Apache/mod_wsgi,如果WSGI应用程序以这种方式出错,则应该将警告消息记录到Apache错误日志中.其他一些WSGI服务器,例如uWSGI,默默地将错误纠正为优化,即使在技术上违反了WSGI规范以及它应该如何处理结果.静默纠正它的WSGI服务器是不好的做法,因为它提供了一种错误的安全感,它工作正常,但是当你转移到符合WSGI规范的WSGI服务器时,性能会降低.
为了确定这些原因中的哪一个,New Relic Python代理还为每个响应记录有关响应中返回的字节数以及产生了多少单独字符串的自定义度量.当您有一个缓慢的事务样本跟踪时,这些将显示在'WSGI/Output/Bytes'和'WSGI/Output/Calls/yield'下的跟踪摘要中.还有'WSGI/Output/Time',它记录从发送的第一个字节到发送的最后一个字节的时间.如果它有助于在整个WSGI应用程序中获取这些视图,那么这些也可以使用自定义仪表板进行制图.
现在和上面一样,另一个问题也可以发挥作用,其中返回的iterable不仅仅是一个列表,而是一个生成器或自定义迭代.
在这种情况下,"WSGI/Response"还记录了WSGI应用程序生成每个产生的字符串所花费的时间.因此,如果WSGI应用程序以某种方式按需计算响应时生成响应缓慢,那么这也会导致"WSGI /响应"下记录的时间增加.
总的来说,在'WSGI/Response'下记录的可能很多,主要的事情是:
在某些情况下,特别是对于实现服务器推送或提供非常大的响应的WSGI应用程序,这次包含在响应时间中可能是一个问题,并且整个Web应用程序的响应时间的平均值会出现偏差.
将百分位视图用于响应时间而不是平均值可以帮助区分这些异常值,但在其他情况下可能需要一些额外的工作.
在这些特殊情况下,可以做的是在处理程序中使用Python代理API来处理受影响的Web事务,过早地终止事务的记录,以便不计算在交付响应时花费的任何过多时间.还有一些选项可以完全禁用对特定Web事务的监视,或者可以标记Web事务以便将其记录为后台任务,从而消除它们对Web事务平均值对响应时间的任何影响.
用于这些目的的三个代理API函数是:
使用Apache/mod_wsgi时,您还可以通过Apache 配置文件应用这些功能.例如,您可以使用以下方法标记要忽略的特定URL:
<Location /some/sub/url>
SetEnv newrelic.ignore_transaction true
</Location>
为了更好地了解正在发生的事情.如果时间是由于大响应或HTTP客户端速度慢造成的,那么除了针对输出字节,产量调用数等的慢事务样本查看事务度量标准记录之外,您还可以做更多的事情.
如果iterable实际上是一个正在工作的生成器,那么通过在New Relic中使用关键事务和X-Ray会话来获取线程配置文件转储,您可以获得更好的洞察力.这将帮助您缩小花费时间的范围.为了获得更持久的可见性,您可以在代码中应用其他函数跟踪,以便跟踪WSGI应用程序产生响应时调用的其他函数,并在性能细分中显示.