python - 在 NewRelic 上使用 mod_wsgi 分析 django 的高 WSGI/响应时间数据

Question

项目部署为:django with apache mod_wsgi

将 New Relic lite 版本配置为跟踪网络性能。
在 New Relic -> Monitoring -> Web transactions 面板 -> Sort on Most time sumption -> Selecting on First entry -> Breakdown Table -> WSGI/Response 似乎消耗了 81% 的时间

在这种情况下，WSGI/响应究竟是什么意思

包含哪些子组件

是否可以获得 WSGI/响应的分割表

如此高的 WSGI/响应时间百分比可能存在哪些问题

对此进行分析有什么好主意吗？ (仅限免费解决方案)

Answer 1

考虑一个简单的 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' 正在跟踪第二阶段以及从返回的可迭代对象中消耗字符串所花费的时间。

要理解为什么“WSGI/Response”可能会显示大量时间，有必要更深入地了解实际发生的情况。

第一个不明显的事情是，在每个字符串从可迭代对象中产生后，WSGI 服务器必须将该字符串写回发出请求的 HTTP 客户端。它不需要等到客户端收到它，但它确实需要做足够的事情来确保在它从迭代中获取下一个字符串后，交付将继续并行。

因此，“WSGI/Response”记录的时间不仅包括从 WSGI 应用程序返回的可迭代对象中产生每个项目所花费的时间，还包括将响应写回 HTTP 客户端所花费的时间。

由于它包括回写响应所花费的时间，因此可能会出现一些问题。

这些是，非常大的响应可能需要时间来回写。如果底层 Web 服务器在任何时候阻塞，那么缓慢的客户端或网络可能会使该时间更长。最后，如果 WSGI 应用程序产生大量小字符串，而不是单个字符串，或者至少是较少数量的大字符串，那么它本身会使情况变得更糟。

最糟糕的情况是一个 WSGI 应用程序，它有一个错误，它返回一个字符串对象作为结果，而不是一个列表或产生字符串的可迭代对象。这是不好的，因为字符串中的每个单个字符将一次写入一个，并发生相应的刷新以将其写回客户端。这会导致过多的开销并增加花费的时间。

如果使用 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 应用程序中查看这些内容，也可以使用自定义仪表板绘制这些内容的图表。

现在和上面一样，另一个问题也可以发挥作用，其中返回的可迭代对象不仅仅是一个列表，而是一个生成器或自定义可迭代对象。

在这种情况下，“WSGI/Response”还记录了 WSGI 应用程序生成每个产生的字符串所花费的时间。因此，如果 WSGI 应用程序在以某种方式按需计算响应时缓慢生成响应，那么这也会导致“WSGI/响应”下记录的时间增加。

所以总的来说，在“WSGI/Response”下记录了很多潜在的事情，主要的事情是:

从 WSGI 应用程序返回的可迭代对象中生成构成响应的所有字符串所花费的时间。

将响应写回发出请求的 HTTP 客户端所花费的时间。

在某些情况下，特别是对于实现服务器推送或交付非常大响应的 WSGI 应用程序，这个时间包含在响应时间中可能是一个问题，并且整个 Web 应用程序的响应时间的平均值会出现偏差。

对响应时间使用百分位数 View 而不是平均值有助于区分这些异常值，但在其他情况下，可能需要做一些额外的工作。

在这些特殊情况下，可以做的是在处理程序中使用 Python 代理 API 来处理受影响的 Web 事务，提前终止事务的记录，以便不计算交付响应所花费的过多时间。还有一些选项可以完全禁用对特定 Web 事务的监视，或者可以标记 Web 事务以便将其记录为后台任务，从而消除它们对 Web 事务平均响应时间的任何影响。

用于这些目的的三个代理 API 函数是:

newrelic.agent.end_of_transaction()

newrelic.agent.ignore_transaction()

newrelic.agent.set_background_task()

使用 Apache/mod_wsgi 时，您还可以通过 Apache configuration 应用这些。文件。例如，您可以使用以下方法标记要忽略的特定 URL:

<Location /some/sub/url>
SetEnv newrelic.ignore_transaction true
</Location>

至于如何更好地了解正在发生的事情。如果时间是由于大量响应或缓慢的 HTTP 客户端造成的，那么除了查看针对输出字节、yield 调用数量等缓慢事务样本的事务度量记录之外，您无能为力。

如果迭代器实际上是一个正在工作的生成器，那么您可以通过使用 New Relic 中的关键事务和 X-Ray session 来获得线程配置文件转储，从而获得更好的洞察力。这将帮助您缩小时间花费的范围。为了获得更持久的可见性，您可以应用额外的 function traces到您的代码，以便在 WSGI 应用程序产生响应时调用的附加函数也被跟踪并显示在性能分解中。