自从4月28日我们从ASP.NET线程的角度对“黑色30秒”问题进行分析之后，我们采用了新的线程设置，然后观察“黑色30秒”是否再次出现。
<processModel enable="true" requestQueueLimit="5000" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" minIoThreads="50"/>
采用以上设置之后，Requests Queued出现的频率的确少了。之后的几天，也没出现“黑色30秒”。
于是，ASP.NET线程设置问题引起“黑色30秒”的可能性已经提升到了99.9%，对阿里云的怀疑只剩下0.1%。
但是：
1. 上次的总结中提到“如果把'黑色30秒‘问题归因于ASP.NET线程问题，除了30秒左右的这个时间，其他问题表现都得到了更合理的解释。”，评论中也有朋友提到“不像是这个问题。为什么是30秒而不是20秒，或者50秒？”，这个最显著的特征却一直找不到合理的解释，让人无法划上圆满的句号。
2. 之前观察的阶段处于五一假期前夕，流量有所下降，没有出现真正的访问高峰，所以需要通过这周的访问高峰进行验证。当阿里云客服想结束工单时，我们说还需要这周的观察。
。。。
结果，今天下午神奇的“黑色30秒”再次降临，而这次“黑色30秒”期间没有出现Requests Queued，请看以下的Windows性能监视器的监视情况。
这次只看4个指标：Requests Executing，Processor Time，Request Execution Time，Current Connections。
1. Requests Executing如过山车
这是这次“黑色30秒”期间最最显著的表现。
2. CPU先抑后扬
3. Request Execution Time在玩蹦极
4. Current Connections有点像撑杆跳
5. 4个指标的叠加
从上面的表现来看，很明显，“黑色30秒”期间正在执行的请求卡住了，或者更准确地说正在执行请求的线程卡住了。
与之前的表现（如下图Requests Queued的上升）相比，这次似乎是新的情况。
根本不是！这只是同一个问题在不同条件下的表现——
之前由于线程设置的少，所以当当前处理请求的线程卡住后，后续的请求只能排队。
而这次当当前处理请求的线程卡住后，后续的请求过来时，ASP.NET可以有更多空闲线程处理这些请求，而在请求处理过程中这些线程也卡住了，所以表现为Requests Executing飙升。
现在我们猜测“黑色30秒”的触发条件是在高并发下线程突然卡住了。
为什么线程会卡住？为什么会是30秒？应用程序的原因，Windows的原因，还是阿里云的原因？大家可以投投票。
如果您对Xen有研究，期待您从dom0 CPU调度策略角度分析可能的原因。