检测 ASP.NET 网站的出站连接队列

Question

有什么方法可以检测到尝试的出站连接何时排队？

我们的 ASP.NET 应用程序向其他 Web 服务发出大量出站请求。最近我们遇到了主要的性能问题，对特定端点的调用需要几秒钟才能完成或超时。该服务的所有者没有看到任何性能问题。当我们分析网络流量时，我们看到确实，HTTP 请求正在及时完成。那时我们才发现我们的长等待时间和超时是由于连接排队造成的。

我们解决此问题的第一种方法是简单地增加允许到该端点的出站连接数，因此：

<system.net>
  <connectionManagement>
    <add address="http://some.endpoint.com" maxconnection="96" />
  </connectionManagement>
</system.net>

这确实使我们对端点的调用大大中断了。但是，我们注意到这导致我们的整体入站请求需要更长的时间才能完成。就在那时我们遇到了Microsoft KB 821268。按照那里的“经验法则”指南，我们提出了这些额外的更改：

<processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50"/>
<httpRuntime minFreeThreads="704" minLocalRequestFreeThreads="608"/>      

这似乎修复了一切。我们对some.endpoint.com 的调用仍然很快，而且我们的响应时间也缩短了。

然而，几天后，我们注意到我们的网站性能不佳，并且我们看到一些 SQL Server 超时。我们的 DBA 没有发现服务器性能有任何问题，所以这看起来像是再次发生了类似的事情；我们想知道与some.endpoint.com 的连接增加是否导致其他 出站调用排队，可能是由于线程不足。

最糟糕的是，我们还没有找到一种很好的技术来明确地知道出站连接排队是否正在发生。我们所能做的就是观察我们发出请求和在应用程序中收到响应之间的时间。很难知道超时和长响应时间是否是由于排队造成的。

是否有任何有效的工具来衡量和调整出站请求限制？任何其他性能调整技巧肯定也会受到赞赏。

Answer 1

Nagle算法

Nagling 是对发送方的 TCP 优化，它旨在 通过将小型发送请求合并到网络中来减少网络拥塞 较大的 TCP 段。这是通过阻止小段来实现的 直到 TCP 有足够的数据来传输一个完整大小的段，或者 直到接收方确认所有未完成的数据

但是 Nagling 与 TCP 延迟 ACK 的交互很差，这是一个 TCP 接收机优化。它旨在减少数量 通过将 ACK 延迟一小段时间来确认数据包。 RFC 1122 指出延迟不应超过 500 毫秒，并且应 是每隔一段的 ACK。由于接收方延迟了 ACK 发送者在发送一小段之前等待ACK， 在延迟的 ACK 到达之前，数据传输可能会停止。

来源here

TL;DR

您的服务器似乎很“健谈”，一直在发出大量请求和响应，试试这个：

ServicePointManager.UseNagleAlgorithm = false;

Answer 2

您描述的问题涉及诊断的许多领域，我想没有一种简单的工具可以让您说出您是否遭受争用。从您的描述看来，您正在耗尽连接或线程池。这通常涉及线程锁定。除了@Simon Mourier 指向的HttpWebRequest Average Queue Time 性能计数器（记得在config file 中设置performancecounters="enabled"）之外，还有其他需要监控的。我将从监视 ASP.NET 应用程序中线程池使用情况的自定义性能计数器开始 - 不幸的是，它们不包含在框架计数器中，但它们实现起来相当简单，如 here 所示。此外，我编写了一个简单的 powershell 脚本，它将为您在应用程序中的线程状态分组。您可以从here 获得它。它类似于 Linux 中的 bit top 命令，会显示进程的线程状态或线程等待原因。查看 2 个应用程序（均名为 Program.exe）的屏幕截图：

一个饱受争议的人

> .\ThreadsTop.ps1 -ThreadStates -ProcMask Program

Threads states / process

Process Name    Initialized       Ready     Running     Standby  Terminated     Waiting  Transition     Unknown
------------    -----------       -----     -------     -------  ----------     -------  ----------     -------
Program                   0           0           0           0           0          22           0           0

并且等待线程的数量不断增长

> .\ThreadsTop.ps1 -ThreadWaitReasons -ProcMask Program

Legend:
 0  - Waiting for a component of the Windows NT Executive| 1  - Waiting for a page to be freed
 2  - Waiting for a page to be mapped or copied          | 3  - Waiting for space to be allocated in the paged or nonpag
ed pool
 4  - Waiting for an Execution Delay to be resolved      | 5  - Suspended
 6  - Waiting for a user request                         | 7  - Waiting for a component of the Windows NT Executive
 8  - Waiting for a page to be freed                     | 9  - Waiting for a page to be mapped or copied
 10 - Waiting for space to be allocated in the paged or nonpaged pool| 11 - Waiting for an Execution Delay to be resolve
d
 12 - Suspended                                          | 13 - Waiting for a user request
 14 - Waiting for an event pair high                     | 15 - Waiting for an event pair low
 16 - Waiting for an LPC Receive notice                  | 17 - Waiting for an LPC Reply notice
 18 - Waiting for virtual memory to be allocated         | 19 - Waiting for a page to be written to disk

Process Name      0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18  19
------------      -   -   -   -   -   -   -   -   -   -  --  --  --  --  --  --  --  --  --  --
Program           1   0   0   0   0   0  34   0   0   0   0   0   0   0   0   3   0   0   0   0

和其他正常运行：

> .\ThreadsTop.ps1 -ThreadStates -ProcMask Program

Threads states / process

Process Name    Initialized       Ready     Running     Standby  Terminated     Waiting  Transition     Unknown
------------    -----------       -----     -------     -------  ----------     -------  ----------     -------
Program                   0           1           6           0           0          20           0           0

等待线程数不超过 24。

> .\ThreadsTop.ps1 -ThreadWaitReasons -ProcMask Program

Legend:
 0  - Waiting for a component of the Windows NT Executive| 1  - Waiting for a page to be freed
 2  - Waiting for a page to be mapped or copied          | 3  - Waiting for space to be allocated in the paged or nonpag
ed pool
 4  - Waiting for an Execution Delay to be resolved      | 5  - Suspended
 6  - Waiting for a user request                         | 7  - Waiting for a component of the Windows NT Executive
 8  - Waiting for a page to be freed                     | 9  - Waiting for a page to be mapped or copied
 10 - Waiting for space to be allocated in the paged or nonpaged pool| 11 - Waiting for an Execution Delay to be resolve
d
 12 - Suspended                                          | 13 - Waiting for a user request
 14 - Waiting for an event pair high                     | 15 - Waiting for an event pair low
 16 - Waiting for an LPC Receive notice                  | 17 - Waiting for an LPC Reply notice
 18 - Waiting for virtual memory to be allocated         | 19 - Waiting for a page to be written to disk

Process Name      0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18  19
------------      -   -   -   -   -   -   -   -   -   -  --  --  --  --  --  --  --  --  --  --
Program           1   0   0   0   0   0  18   0   0   0   0   0   0   0   0   6   0   0   0   0

当然，在您的情况下线程数会高得多，但您应该能够在“平静时期”观察线程行为的一些趋势，并且当您遭受争用时等待队列高峰。

您可以随意修改我的脚本，以便它将这些数据转储到控制台以外的其他地方（如数据库）。最后，我建议运行诸如Concurrency Visualizer 之类的分析器，它可以让您更深入地了解应用程序中的线程行为。启用system.net trace sources 也可能会有所帮助，尽管事件的数量可能会很大，因此请尝试相应地调整它。

Answer 3

您在这里描述的是一个非常复杂的问题。您的应用程序基本上处于其他几个事物的中间，SQL Server、Web 服务提供商等，您正试图找出慢的地方。您依赖的是您的应用程序还是其他人的应用程序。

我自己尝试设置性能监视器和挖掘日志等，但发现它非常耗时且难以想象一段时间内实际发生的情况。收集数据并查看某个时间点很容易。很难查看所有数据并使其在一段时间内有意义，尤其是在涉及大量连接系统的情况下。

如果我是你，我会尝试免费的 NewRelic 试用版：http://newrelic.com/application-monitoring 我以前使用过他们的产品，发现它对于解决此类问题非常有用。