2

在 IIS7.5 环境中，我已将 aspnet.config 配置为将 MaxConcurrentRequestsPerCPU 设置为 1。

我正在这个 IIS 实例上执行一个 Web 服务，我已为其配置公开 MaxConcurrentRequestsPerCPU 和 MaxConcurrentThreadsPerCPU 以响应 ASMX Web 服务中的 WebMethod，这允许我通过 Web 服务确认 .NET 框架正在正确读取这些值，因此它们应该被 IIS 正确使用，只需让 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 时，这仍然是正确的。

谁能解释为什么这些设置似乎被忽略了，或者在这种情况下似乎无法正常工作？

4

1 回答 1

0

为了测试这一点（这是一个非常奇怪的测试，没有人应该在生产中做这样的事情），你需要将 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），有利于通过请求数来控制并发，主要是因为 maxConcurrentRequestsPerCPU 性能更好（控制线程数量更复杂/实现成本更高）。通常您会使用请求门控，但您现在可以选择禁用它（设置 maxConccurrentRequestsPerCPU=0）并启用 maxConccurentThreadsPerCPU。您还可以同时启用请求和线程门控，ASP.NET 将确保满足这两个要求。requestQueueLimit 设置与 processModel/requestQueueLimit 相同，只是 aspnet.config 中的设置将覆盖 machine.config 设置。所有这些可能有点令人困惑，但对于几乎所有人来说，我的建议是对于 ASP.NET 2.0，您应该使用与 ASP.NET v4.0 中的默认设置相同的设置；即设置 maxConcurrentRequestsPerCPU = "5000"

http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx

于 2013-06-24T19:05:01.590 回答