Azure Web App 上的 Http 队列长度指标是什么？答案

【问题标题】：What is the Http queue length metric on Azure Web App?Azure Web App 上的 Http 队列长度指标是什么？
【发布时间】：2016-02-24 17:26:06
【问题描述】：

Azure Web App 上的 Http 队列长度指标是什么？

我的网络应用程序经常超过 150 个。

我很担心，因为可以在应用服务上启用的默认警报的默认阈值为 100。

SignalR 的使用会影响这个指标吗？

编辑：

这是典型的日负荷：

【问题讨论】：

这在 ServerFault 答案中得到解决 - 问题 here。
这意味着您的主机设置正在发出高负载。您的应用服务中有多少个实例？
我们的 S2 应用服务计划有 1 个 Web 应用和 1 个实例。
@GuillaumeMorin，你找到更多了吗？我在托管 SignalR 集线器的应用服务上的行为完全相同。
@JacquesBosch 不。一直这样运行了将近一年，但没有问题。我仍然相信那些是 signalR 持久连接。

标签： azure signalr azure-web-app-service

【解决方案1】：

Http Queue Length：待处理的 HTTP 操作的计数。如果您的应用程序接收到的请求超出了 Web 服务器的处理能力，那么这可能是您的差距。这意味着存在请求的后果，并且您当前的配置不足以支持负载。使用 portal.azure.com 默认的 HTTP 队列长度从 1 开始

我认为您将 SignalR 用于套接字，而套接字正在维护与您的网络服务器的连接，HTTP 队列长度是 Azure 排队的网络请求的计数，因为它无法再处理，所以可以是，但除非我们进一步分析，否则不确定。

【讨论】：

Cpu avg=10% 和 Memory avg=40%，所以看起来资源没有过载
CPU 和内存不是导致长请求的唯一指标。其他一些依赖，如 sql 调用可以增加响应时间和 http 队列。您可以增加 AppService 的实例数。我很确定队列会减少。

【解决方案2】：

如果请求进入 HTTP 队列，则意味着没有线程可用于处理请求。正如 Kerem 所暗示的那样，可能有一些长时间的 I/O 调用使线程进入等待状态（无法为请求提供服务）。这很可能是因为 CPU 和内存不足。

您可以在 enter/exist 方法上添加 Diagnostic.Trace 并检查应用程序日志从这些方法进出需要多长时间

另一种方法是远程连接 Visual Studio 并查看线程在做什么。有多少人在等？

另一种方法是进行内存转储（可能来自 kudu 站点）。然后检查线程在做什么：在 WinDbg 中： !CLRStack -a *~ 知识库

您也可以在 Visual Studio 中打开 .dmp 文件，选择非托管，然后检查阈值。如果所有/几乎所有线程都在 WaitFor***Object 中，则它们正在等待 IO 完成。在这种情况下，增加实例化确实会解决/减少问题，但最好更改方法以使用异步版本进行 IO。

hth，阿尔多

【讨论】：

谢谢阿尔多。你知道 SignalR 是否会导致这种情况吗？即，所有客户端都与服务器有一个或多个“长期运行”的 SignalR 连接。我们有大约 75 个并发用户，他们可能打开了多个浏览器选项卡。
我对 SignalR 不熟悉。但是您应该关注在提供连接（或请求）时会发生什么。看起来您正在以同步方式对数据库或其他东西进行一些 I/O 调用，并且执行调用的线程处于等待响应状态并且无法为其他请求提供服务。在重负载下，所有线程都以 WAIT 结束，因此其他请求会排队。您应该将 I/O 请求更改为 async/await，这将避免线程结束等待。 CLR 通过 C# Jeffrey Richter 有一个很好的部分关于异步和 IO 绑定操作 hth, aldo

【解决方案3】：

编辑 2016 年 11 月 12 日

根据一些后续信息，HTTP 队列长度很快就会与预期相符。

我得到确认，修复后，服务器场的 HTTP 队列长度指标将描述实际的 HttpQueueLength（它错误地显示了当前的 Requests 值此时）用于服务器场（应用服务计划）。此修复将未来几周内将在所有地区推出。

在谈到 Azure 支持时，HTTP 队列长度实际上是一个令人困惑的名称，并映射到“W3SVC_W3WP”、“Active Requests”、“_Total”。

这是完整的回复

你好 Shane，你是对的，我们注意到 http queue metric 存在问题，我们在 Auto-Scaling/Alert a Web App 中发现基于该指标具有误导性，因为该指标正在计算活动请求总数而不是排队请求，我们有一个与我们的产品团队讨论此指标并显示度量 HTTP 的名称有一点歧义队列。实际上，我们在门户上显示的柜台对应到“W3SVC_W3WP”、“活动请求”、“_Total”。换句话说，这计数器不代表队列，而是代表请求在当前任何时间运行。我们也通过查看验证了这一点进入我们的产品源代码。我们了解如何命名柜台可能会导致混乱，我们已向我们的产品团队重命名它。产品团队担心重命名可能会破坏客户可能拥有的现有警报，但他们是考虑添加另一个名为“Active Requests”的指标，看起来相同的值，然后删除“HTTP Queue Length”。保持考虑到这一点，我们的建议是使用任何其他指标（对于例如：CPU/内存）来配置自动缩放/警报规则，而不是使用 Http 请求队列。

几天前我又与我们的产品团队进行了讨论我们目前正在努力更新此内容以代表计数器值用于“请求”而不是真正的 Http 队列长度。

虽然这种区别很快就会变得无关紧要，因为他们也有这样的说法

嗨，Shane，我只是在测试这一点，我发现门户已在站点级别更新，以将此指标显示为 “要求” 。我认为我们仍在等待这种变化推送到服务器场设置。

如果我选择警报。在“资源”下拉列表中选择“站点” 选择您的站点，然后指标将列出“请求”，这将是当前的请求。

所以需要注意的是，在当前状态下，该指标并不表示您有系统无法处理的备份请求。

【讨论】：