asp.net - 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限制，但该限制确实很高。

如果您长时间进行网络调用的同步处理和阻塞，则很有可能遇到这些限制。在.NET 4之前需要注意MaxConcurrentRequestsPerCPU，但仍然有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在处理负载方面做得更好。

异步仍然是一个国家(地区)最好的。