解决方法
我一直在做研究,我相信我得到了一个可以接受的答案.我的主要来源是这篇文章：
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限制,但是这个限制真的很高.
如果您在长时间的网络呼叫中进行同步处理和阻止,则更有可能遇到这些限制. 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做了更好的工作来加快处理负载.>异地仍然是国家一英里最好的.
