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

Question

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

我的网络应用程序不断超过150个。

我担心，因为可以在App Service上启用的默认警报的默认阈值为100。

SignalR的使用是否会影响此指标？

修改

这是典型的日负荷：

Answer 1

Http Queue Length：挂起的HTTP操作的计数。如果您的应用程序接收的请求多于Web服务器可以处理的请求，那么这可能是您的差距。这意味着有一个请求的余量，并且您当前的配置不足以支持负载。 使用portal.azure.com，HTTP队列长度的默认值从1开始

我认为你正在使用SignalR for Sockets，而套接字正在维护与你的web服务器的连接，HTTP Queue Length是由Azure排队的web请求的数量，因为它不能再处理，所以是的可能是，但不确定，除非我们进一步分析。

Answer 2

修改 2016年11月12日

根据一些跟进信息，HTTP Queue Length将在不久的某个时间点符合预期。

  

我确认在修复之后，   Server Farm的HTTP队列长度指标将描述实际情况   HttpQueueLength（它错误地显示当前的请求值   此时）用于服务器场（应用服务计划）。这个修复会   将在未来几周内在所有地区推出。

与Azure支持人员讨论HTTP队列长度实际上是一个令人困惑的名称，并映射到＆＃39;＆＃39; W3SVC_W3WP＆＃39;，＆＃39;有效请求＆＃39; _＃Total＆＃39; 。

这里有完整的回复

  

Hello Shane，你是对的，我们注意到了http队列指标的问题，我们发现在自动扩展/警报Web应用程序中   基于这个指标是误导性的，因为这个指标正在计算   总活跃请求而不是排队请求，我们有一个   与我们的产品团队讨论该指标并显示出来   在度量标准HTTP的名称中有一点含糊不清   队列。实际上，我们在门户网站上显示的计数器是对应的   to＆＃34; W3SVC_W3WP＆＃34;，＆＃34; Active Requests＆＃34;，＆＃34; _Total＆＃34;。换句话说，这个   counter不代表队列，而是代表请求   在任何当前时间运行。我们也通过观察验证了这一点   进入我们的产品源代码。我们了解如何命名   计数器可能导致混淆，我们已向我们提交了请求   产品团队将其重命名。产品团队担心重命名   可能会破坏客户可能拥有的现有警报但他们可能会   考虑添加另一个名为“Active Requests”的指标   以相同的值，然后删除“HTTP队列长度”。保持   考虑到这一点，我们的建议是使用任何其他指标（for   例如：CPU /内存）来配置自动缩放/警报规则而不是   使用Http请求队列。

     

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

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

  

嗨，谢恩，我只是在我的结尾测试这个，我看到了   门户网站已在网站级别更新，以显示此指标   “要求” 。我想我们仍在等待这种变化   推送到服务器场设置。

     

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

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

Answer 3

如果请求结束到HTTP队列，则意味着没有可用于处理请求的线程。正如Kerem建议的那样，可能有一些长I / O调用使线程进入等待状态（无法提供请求）。这很可能因为CPU和内存很低。

您可以在enter / exist方法中添加Diagnostic.Trace，并检查应用程序日志进出这些方法所需的时间

另一种方法是，使用Visual Studio远程连接并查看正在执行的线程。有多少人在等？

另一种方法是采取内存转储（也许来自kudu站点）。然后检查线程在做什么： 在WinDbg中： ！CLRStack -a * ~KB

您也可以在Visual Studio中打开.dmp文件，选择unmanaged，然后检查threds。 如果所有/几乎所有线程都在WaitFor ***对象中，那么它们等待IO completition。 在这种情况下，增加实例化将解决/减少问题是正确的，但最好更改方法以使用IO的异步版本。

HTH， 醛