在IIS7.5环境中，我已将aspnet.config配置为将MaxConcurrentRequestsPerCPU设置为1.
我正在IIS的这个实例上执行一个Web服务，我为此配置了公开MaxConcurrentRequestsPerCPU和MaxConcurrentThreadsPerCPU以响应ASMX Web服务中的WebMethod，这允许我通过Web服务确认.NET框架是正确地读取这些值，因此只需让WebMethod从HostingEnvironment对象返回值就可以正确地使用它们。
我还有一个WebMethod，只需将线程休眠5秒钟，简称为TestMethod。
理论上我认为这种设置应该确保后续对TestMethod的调用以串行方式发生，因为每个CPU只允许1个请求，或者，如果每个CPU实际上允许四核系统上的每个核心，最多可以并行处理4个请求，具体取决于它是真正的每个CPU，还是每个核心。
然而，这些似乎都不是这样。对于此方法的20个同时请求，我希望看到大约100秒（20个请求x 5秒）或25秒（（20个请求/ 4个核心）x 5秒）的完成时间。相反，我总是以10秒的完成时间结束，这意味着尽管并发请求限制设置为1，仍然会并行处理10个请求。当我还将每个CPU的并发线程也设置为1时，这仍然是正确的。
有人可以解释为什么这些设置似乎被忽略了，或者在这种情况下似乎无法正常工作？
答案 0 :(得分：0)
要测试它（这是一个非常奇怪的测试，并且NO ONE应该在生产中做这样的事情），你需要将maxConcurrentRequestsPerCPU设置为1，然后将MaxConcurrentThreadsPerCpu设置为0。
原因是ThreadsPerCpu设置是模拟旧式IIS限制（“经典”应用程序池模式）。
相应的IIS 7.5更改（仅限Windows Server 2008 R2） 它允许为每个文件指定不同的aspnet.config文件 应用程序池（此更改尚未移植到IIS 7.0）。同 这样，您可以不同地配置每个应用程序池。该 maxConcurrentRequestsPerCPU设置与注册表项相同 如上所述，除了aspnet.config中的设置 覆盖注册表项值。 maxConcurrentThreadsPerCPU 设置是新的，并允许并发数量的门控 线程，类似于在Classic / ISAPI模式下完成的方式。通过 默认maxConcurrentThreadsPerCPU被禁用（值为0），in 主要是通过请求数量来控制并发性 因为maxConcurrentRequestsPerCPU表现更好（门控号码 线程的实现更复杂/更昂贵）。通常你会 使用请求选通，但您现在可以选择禁用它（设置 maxConccurrentRequestsPerCPU = 0）并启用 相反，maxConccurentThreadsPerCPU。您也可以启用这两个请求 和线程门控同时，ASP.NET将确保两者 要求得到满足。 requestQueueLimit设置与 processModel / requestQueueLimit，但设置中除外 aspnet.config将覆盖machine.config设置。所有这些 可能有点令人困惑，但几乎每个人，我的建议 对于ASP.NET 2.0，你应该使用相同的设置 ASP.NET v4.0中的默认值;也就是说，设置maxConcurrentRequestsPerCPU = “5000”和maxConcurrentThreadsPerCPU =“0”。
http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx