IIS7 集成管道：maxConcurrentRequestsPerCPU 和 requestsQueueLimit 设置之间的交互

Posted 2023-03-30

【中文标题】IIS7 集成管道：maxConcurrentRequestsPerCPU 和 requestsQueueLimit 设置之间的交互

【英文标题】：IIS7 Integrated Pipeline: Interaction between maxConcurrentRequestsPerCPU and requestsQueueLimit settings

【发布时间】：2011-01-19 16:09:19

【问题描述】：

首先，这里对 IIS7 HTTP 请求生命周期和影响性能的各种设置进行了很好的概述：

ASP.NET Thread Usage on IIS 7.0 and 6.0

非常具体，在 dotNet 4 中，ma​​xConcurrentRequestsPerCPU 和 requestsQueueLimit 的默认值设置为 5000。例如相当于：（在 aspnet.config 中）：

<system.web>
   <applicationPool 
      maxConcurrentRequestsPerCPU="5000" 
      maxConcurrentThreadsPerCPU="0" 
      requestQueueLimit="5000" /> (** see note below)
</system.web>

在我看来，在多 CPU/核心服务器上，这里的 requestQueueLimit 总是会在“perCPU”限制之前被调用。因此，如果您真正想要的是每个 CPU 最多 5000 个请求，那么我希望 requestQueueLimit 需要增加到 5000 * CPUCount 或完全禁用。

我的解释正确吗？如果是这样，我可以禁用 requestQueueLimit 吗？ （将其设置为零？）。此设置的文档似乎没有解决这个问题（所以也许我遗漏了什么或误读了？）

** 来自上述文章的旁注：requestQueueLimit 命名不当。它实际上限制了 ASP.NET 可以同时处理的最大请求数。这包括排队的请求和正在执行的请求。如果“Requests Current”性能计数器超过 requestQueueLimit，新的传入请求将被拒绝并返回 503 状态代码）

【问题讨论】：

我已请 Thomas（您指向的帖子的作者）对此发表评论。

【参考方案1】：

***我的解释正确吗？

是的，如果您想同时执行超过 5000 个请求，则需要增加 requestQueueLimit。 requestQueueLimit 限制系统中的请求总数。由于其遗留问题，它实际上是系统中的请求总数，而不是某个队列中的请求数。它的目标是防止服务器由于缺乏物理内存、虚拟内存等而崩溃。当达到限制时，传入的请求将收到快速的 503“服务器太忙”响应。顺便说一句，系统中的当前请求数由“ASP.NET\Requests Current”性能计数器公开。

***我可以禁用 requestQueueLimit 吗？ （设置为零？）

您可以通过将其设置为较大的值（例如 50000）来有效地禁用它。您必须在 aspnet.config 文件中设置该值将其设置为零不会禁用它...奇怪的是，这意味着不能同时执行一个以上的请求。

顺便说一句，v4 中似乎有一个错误。对于集成模式，只有在aspnet.config文件中配置为described on MSDN时才会成功读取requestQueueLimit的值。出于某种原因，当我之前尝试 v4 时，它并没有从 machine.config 中读取它。

【讨论】：

谢谢。也许你可以为我澄清最后一点。如果进行中的请求总数超过 requestQueueLimit，则客户端会收到“503 服务器太忙” - 好的。如果 maxConcurrentRequestsPerCPU 超出/before/ requestQueueLimit，我还会得到 503 吗？也就是说，它们是否都在请求处理生命周期的同一点或多或少地控制请求数量？从我所读到的内容中，这是 IIS 和 ASP.NET 如何演变的遗产。

如果在 requestQueueLimit 之前超过 maxConcurrentRequestsPerCPU，您将不会得到 503。如果在 requestQueueLimit 之前超过了 maxConcurrentRequestsPerCPU，则请求将被添加到队列中。一旦其中一个执行请求完成，它将立即出列。

在集成模式下，全局队列是原生结构。从一开始...HTTP 接收请求并发布到 IIS CP。 IIS 获取 CP 线程上的请求并调用 ASP.NET。如果未超过 requestQueueLimit，则 ASP 调用 QUWI 以发布到 CLR TP。本机回调（在 webengine.dll 中）在 CLR 工作线程上获取请求，我们将 maxConcurrentRequestsPerCPU * CPUCount 与总活动请求进行比较。如果我们超过了限制，请求被插入到全局队列中（本机代码）。否则，它将被执行。如果它已排队，则会在其中一个活动请求完成时出列。

感谢 Thomas，这非常有用。我们也只是对我认为不再适用于集成管道的 minFreeThreads 设置感到好奇——是否有类似的设置我们应该设置或方法，或者我们不必担心线程耗尽？我在这个阶段的猜测是 maxConcurrentRequestsPerCPU 应该设置/低于/ maxWorkerThreads 以确保有足够的线程来处理每个请求。但是默认值是 maxConcurrentRequestsPerCPU=5000 而 maxWorkerThreads 要低得多（我认为是 100 或 250）。

minFreeThreads 设置适用于经典模式。集成模式的类比是 maxConcurrentThreadsPerCPU，在集成模式下默认禁用（即值为 0）。如果您想继续，请将此讨论转到我的博客。默认设置适用于大多数人，但并非所有人。这取决于你在做什么。理想情况下，我们会自动调整，但我们还没有实现。

【参考方案2】：

您可能想查看this 应用程序的源代码。 IIS Tuner 是一个开源应用程序，它优化 IIS 设置以获得更好的性能。另一方面，this 页面可能对您的问题有用。