ASP.NET如何确定是否对请求进行排队？

Question

当ASP.NET收到请求时,它如何确定是为其提供服务还是对其进行排队？我问,因为我正在监视服务器上的性能计数器并且CPU没有达到最大值并且有大量可用的工作线程,但我仍然看到多达200个请求排队.

Answer 1

我一直在做研究,我相信我已经得到了一个可以接受的答案.我的主要来源是这篇文章:http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0的.aspx

据我所知,请求处理有两种主要方式受到限制.第一个是MaxConcurrentRequestsPerCPU属性.在.NET 4之前,默认设置为12.在.NET 4中,它被更改为5000.对于异步请求,他们希望允许很多,而对于同步请求,他们认为ASP.NET ThreadPool会很好地限制同步请求.第二个当然是ThreadPool本身.在ASP.NET发布请求后,它可以决定它何时发布.

如果您正在进行异步处理,那么您的限制因素可能是CPU,网络和磁盘,而不是任何ASP.NET请求限制.它可能会达到MaxConcurrentRequestsPerCPU限制,但该限制非常高.

如果您长时间在Web呼叫上进行同步处理和阻止,则更有可能遇到这些限制.MaxConcurrentRequestsPerCPU在.NET 4之前需要注意,但仍然存在ThreadPool.

性能测试
我将一个简单的测试放在一起,看看这个限制是如何工作的.我有一个500ms Thread.Sleep()调用的简单页面.一台主机同时发出800个异步请求,一台运行ASP.NET的工作机器处理它们.结果很有趣:

.NET 3.5,没有修改:46秒.使用进程资源管理器看到9个工作线程.
.NET 3.5,MaxConcurrentRequestsPerCPU设置为5000:46秒.9个工作线程.
.NET 4:42秒,或者在热运行时为13秒.看到大约35个工作线程逐渐被创建.
.NET 4,异步:3秒

一些观察:

• MaxConcurrentRequestsPerCPU没有被击中.看起来这是ThreadPool本身的限制.
• .NET 3.5似乎不太愿意创建新线程来处理同步请求..NET 4在提升处理负载方面做得更好.
• Async在乡村英里仍然是最好的.