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

在这篇博文中，我们将聚焦于从ASP.NET的角度去分析和解读“黑色30秒”这一让人困惑的现象，看看是否能在问题的背后找到更为合理的解释。我们暂且搁置对阿里云的疑虑，深入这个问题的本质。

现象的核心特征是请求排队（Requests Queued）数量激增，HTTP.SYS的到达请求数（Arrival Rate）以及每秒请求数（QPS）骤然下降，而CPU消耗却出现下滑，当前连接数（Current Connections）却不断攀升。

就在昨天晚上18:08，我们的系统经历了一次典型的“黑色30秒”。以此为案例，让我们进一步问题的实质。

我们来为什么Requests Queued会突然增加。

最直接的原因是ASP.NET的线程池中无可用的处理请求的工作线程。那么，为什么会出现这种情况呢？ASP.NET的线程池中的可用线程数量是有限的，可能由于瞬间并发请求的数量过多，导致ASP.NET无法及时创建足够的线程来处理这些请求。

让我们来关注一下ASP.NET中与线程相关的设置。在machine.config中的processModel部分（位于C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config），我们看到了关于最大、最小工作线程数（maxWorkerThreads、minWorkerThreads）以及最大、最小I/O线程数（maxIoThreads、minIoThreads）的设置。在默认设置下，对于每个CPU核，都有相应的线程数量限制。在我们8核的Web服务器上，实际的线程数量设置可能导致了问题的出现。

基于上述设置，当瞬间并发请求数量超过预估的可用线程数量时，就会出现请求排队的情况。例如，如果平时并发请求数是300，突然某个时刻并发请求数飙升至600，超出了ASP.NET的预估能力，那些等待处理的请求只能排队等待可用的线程。随着时间的推移，当释放的线程和新建线程足够处理排队的请求时，系统便恢复了正常。为了验证这一猜测，我们调整了相关的设置，提供更多的可用线程。如果调整后的设置能有效减少“黑色30秒”现象的出现，那么就可以证实问题确实出在可用线程不足上。目前我们正在观察调整后的效果。通过Windows性能监视器监视Requests Queued可以直观地评估ASP.NET应用程序的吞吐能力。采用ASP.NET异步编程可以有效减少因可用线程紧张导致的请求排队问题。那么为什么Arrival Rate会下降呢？这是“黑色30秒”问题中最令人困惑的部分。在监视图中可以看到，尽管ASP.NET中的请求出现排队，但到达HTTP.SYS的请求数却下降了。后来我们意识到，这可能是因为用户在等待请求处理期间选择了放弃或跳转至其他页面导致的。由于长时间的等待和延迟响应，用户可能会选择关闭页面或进行其他操作，从而导致到达HTTP.SYS的请求数下降。这个问题提醒我们：在设计和优化系统时，必须考虑到用户体验的重要性以及可能的用户体验波动对系统性能的影响。“黑色30秒”问题是一个复杂且有趣的现象，涉及到ASP.NET的性能调优和用户体验的优化等多个方面。我们需要继续深入研究并调整相关设置以优化系统的性能并提升用户体验。揭开“黑色30秒”的神秘面纱：深入ASP.NET的请求排队现象

当我们面对网站或服务的性能问题时，有时会遇到一种神秘的“黑色30秒”。在这短暂的时间内，网站似乎遭遇了前所未有的挑战，性能指标急剧波动。我们将深入这一现象背后的原因，并尝试其与ASP.NET请求排队之间的关系。

当你的浏览器首次请求一个html页面并成功获得响应时，页面加载过程中会发出多个ajax请求。这些ajax请求可能会在浏览器等待首个请求完成期间被暂时搁置。这种现象背后其实是浏览器与服务器之间的交互逻辑。当服务器处理首个请求时，如果队列中的ajax请求数量较多，它们可能会被暂时搁置，直到服务器处理完当前任务。这就解释了为何在某些时刻，到达HTTP.SYS的请求数会出现飙升——那些原本被搁置的请求在服务器完成当前任务后迅速发出。

【启示】：我们不能仅局限于眼前的问题表象，而应该深入思考、综合考量，各种现象之间的内在联系。

接下来，我们来谈谈其他几个相关的现象：

3、QPS下降：与Arrival Rate的下降有着同样的逻辑基础。QPS（每秒请求数）与Arrival Rate之间存在正相关关系。当请求被暂时搁置时，QPS也会出现下降。这也验证了我们的推测：问题背后可能存在着请求排队的现象。

4、CPU消耗下降：随着请求的减少和排队现象的出现，CPU的工作量自然减少，导致CPU消耗下降。这也是请求排队带来的直接影响之一。

5、Current Connections上升：这是一个直接反映请求排队的指标。当请求尚未被执行时，连接会保持活跃状态。Current Connections的上升为我们提供了请求排队的直观证据。

而在这一系列现象中，一个新的指标引起了我们的关注——Requests Executing。在请求排队期间，正在被ASP.NET执行的请求数在增加。这说明随着更多的线程被释放和创建，队列中的请求正在逐步被执行。这也从侧面反映出执行中的线程并未被卡住，而是受到了可用线程数量的限制。

进一步查看IIS日志中的time-taken信息，我们发现在这段时间内没有超过1秒的处理请求！这说明了正在执行的请求处理速度非常快。结合之前的分析，我们可以得出一个结论：除了因为可用线程不足导致的请求排队外，其他地方一切正常。

在这一问题的过程中，我们不断挖掘新的证据和信息，逐步将可能的诱因归结为ASP.NET线程问题。写完这篇博客前的初步推测是这种问题可能与ASP.NET线程问题的关联度达到80%，但在深入分析后，我们认为这种可能性已经上升到99%。接下来的关键是通过设置新的线程参数进行验证。我们将继续关注这一过程，因为对我们来说更重要的是解决问题的过程本身。我们期待通过这次经历进一步提升我们的问题解决能力。

我们将使用新的线程设置进行验证并密切关注结果。让我们期待这一“黑色30秒”问题得到圆满解决的过程吧！