阿里云上从ASP.NET线程角度对“黑色30秒”问题的

在这篇博文中，我们抛开对阿里云的怀疑，完全从ASP.NET的角度进行分析，看能不能找到针对问题现象的更合理的解释。

“黑色30秒”问题现象的主要特征是排队的请求（Requests Queued）突增，到达HTTP.SYS的请求数（Arrival Rate）下降，QPS（Requests/Sec）下降，CPU消耗下降，Current Connections上升。

昨天晚上18:08左右发生了1次“黑色30秒”，正好借此案例分析一下。

1、为什么Requests Queued会突增？

最直接的原因是ASP.NET没有可用的线程处理当前请求。为什么会没有可用的线程呢？ASP.NET可用的线程毕竟是有限的，可能是当时瞬间的并发请求太多，ASP.NET来不及创建足够的线程处理这些请求。

我们来看一下ASP.NET中线程相关的设置——machine.config中的processModel（位于C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config）。

有4个相关设置maxWorkerThreads（默认值是20）, maxIoThreads（默认值是20）, minWorkerThreads（默认值是1）, minIoThreads（默认值是1）。（这些设置是针对每个CPU核）

我们用的就是默认设置，由于我们的Web服务器是8核的，于是实际的maxWorkerThreads是160，实际的maxIoThreads是160，实际的minWorkerThreads是8，实际的minIoThreads是8。

基于这样的设置，是不是如果瞬间并发请求是169，就会出现排队？不是的，ASP.NET没这么傻！因为CLR 1秒只能创建2个线程，等线程用完时才创建，黄花菜都凉了。我们猜测ASP.NET只是根据这个设置去预测线程池中的可用线程是不是紧张，是不是需要创建新的线程，以及创建多少线程。

那什么情况下会出现“黑色30秒”期间那样的大量请求排队？假如并发请求数平时是300，突然某个瞬间并发请求数是600，超出了ASP.NET预估的所需的可用线程数，于是那些拿不到线程的请求只能排队等待正在执行的请求释放线程以及CLR创建新的线程。随着时间的推移，释放出来的线程+新创建的线程足以处理这些排队的请求，就恢复了正常。

那如何验证这个猜测呢？ 修改maxWorkerThreads, maxIoThreads, minWorkerThreads, minIoThreads的设置，让ASP.NET提供更多的可用线程，目前我们采用的设置如下

<processModel enable="true" requestQueueLimit="5000" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" minIoThreads="50"/>

如果采用这个设置之后，“黑色30秒”现象几乎不出现，就能验证问题出在这个地方。现在主站.blogs.已经使用了这个设置，需要观察一段时间进行验证。

【启示】

1) 通过Windows性能监视器监视\ASP.NET\Requests Queued可以直观地评估ASP.NET应用程序的吞吐能力（throughput）。

2) 通过ASP.NET异步编程（async/await）可以有效减少可用线程紧张造成的请求排队问题。

2、为什么Arrival Rate会下降？

（上图中的橙色线条）

这是“黑色30秒”问题中最让人不解的地方，ASP.NET中请求再怎么排队，怎么会造成到达HTTP.SYS的请求数下降呢？一开始我们总是不相信是请求排队引起的Arrival Rate下降，监视图中却铁证如山。

写这篇博客之前，我们突然想通了！之前忽略了一个地方——当你打这篇博文时，第1个请求是html页面，如果这个请求得到正常响应，浏览器在加载这个页面时会发出多个ajax请求；如果第1个请求被排队，浏览器处于等待状态，后续的ajax请求就不会发出，这样到达HTTP.SYS的请求数就会下降。这也解释了为什么有时会在“黑色30秒”的中间阶段Arrival Rate会飙高，正是因为当时被排队的请求所对应的页面中有很多ajax，当它结束排队被执行后，后续的很多ajax请求（可能排队的很多是这样的请求）到达了HTTP.SYS。

于是，我们相信了是请求排队引起的Arrival Rate下降。

【启示】

不能把目光局限于当前看到的问题表现，而要综合考虑，将诸多因素联系起来理清各种现象之间的关系。

3、QPS下降

与Arrival Rate下降同理，QPS(Requests/Sec)与Arrival Rate是直接相关的，成正比关系。

于是，QPS下降也是因为请求排队。

4、CPU消耗下降

也是同理，Arrival Rate与QPS下降，说明CPU要干的活少了，自然消耗就下降。

于是，CPU消耗下降也是因为请求排队。

5、Current Connections上升

Current Connections是请求排队的一个直接表现，请求还没被执行，连接会保持着。

于是，Current Connection上升也是因为请求排队。

6、看一个新指标Requests Executing

（上图绿色的线条表示的是Requests Executing）

在请求排队的期间，正在被ASP.NET执行的请求数（Requests Executing）在增加，说明随着被释放出来的线程增多以及更多的新线程被创建，排列中的请求正在被越来越多地执行。这从侧面说明了执行中的线程可能是正常的，没有被卡住。（接下来的IIS日志信息会进一步验证这一点）

于是，Requests Executing在增加也是因为请求被排队，而且说明这个排队是正常的，没有哪个地方卡住了。

7、再来看看IIS日志中请求的time-taken

在“黑色30秒”阶段，IIS日志中没有time-taken超过1s的请求！这说明了什么？说明了正在被执行的请求处理速度很快，没有什么地方被卡住。。。除了因为可用线程不够，请求被排队。

于是，IIS日志说明除了请求排队，其他地方一切正常。

【】

如果把“黑色30秒”问题归因于ASP.NET线程问题，除了30秒左右的这个时间，其他问题表现都得到了更合理的解释。

写这篇博客之前，我们当时觉得ASP.NET线程问题引起“黑色30秒”问题的可能性是80%，写完这7点分析之后，我们觉得可能性是99%，除非这次分析的“黑色30秒”与之前的“黑色30秒”不是同一个问题。

现在还需要我们使用新设置(maxWorkerThreads="100", maxIoThreads="100", minWorkerThreads="50", minIoThreads="50")之后的验证。

大结局即将来临，重要的可能不是结局是什么，而是其中的过程，我们分享的也是解决问题的过程。