.net - 为什么即使请求执行低于其限制，请求排队仍然很高？

Question

为什么即使请求执行低于其限制，请求排队仍然很高？

我们正在使用以下设置

• 目标框架:.Net 3.5 框架
• 应用程序池:具有托管管道模式的 .Net Framework v2.0.50727 – 集成
• 并且，没有 CPU 是 8，所以 maxconcurrentRequestperCPUx8=96
• 内存:24GB

在 machine.config 和 aspnet.config 中使用默认设置

我们使用 ACT 进行了测试并获取了性能计数器。

ASP.NET Apps v2.0.50727(_LM_W3SVC_2_ROOT)\Requests Executing

ASP.NET v2.0.50727\请求排队

现在我们做了以下更改

在 aspnet.config 中

 <system.web>
      <applicationPool maxConcurrentRequestsPerCPU="5000" maxConcurrentThreadsPerCPU="0" requestQueueLimit="5000"/>
 </system.web>

在 machine.config 中

<system.web>
    <processModel autoConfig="false" maxWorkerThreads="4095" maxIoThreads="4095"    minWorkerThreads="2047" minIoThreads="2047" />
</system.web>

并提供应用程序池队列限制=5000现在我们的请求排队相对较少，执行的请求较多，如下图所示!!

ASP.NET Apps v2.0.50727(_LM_W3SVC_2_ROOT)\Requests Executing

ASP.NET v2.0.50727\请求排队

但令人惊讶的平均。 ACT 的每秒响应时间没有改善。

所以我有以下问题......

1) 为什么即使请求执行低于其限制(在我的情况下，CPU 数量 x maxconcurrentrequestperCPU = 8 x 12 = 96)，请求也会排队？

2) 即使更改了 aspnet.config、machine.config 并提供应用程序池队列限制=5000，为什么仍会观察到请求排队？

3) 为什么 ACT 响应时间没有随着 Request Executing Counter 的提高而提高？

感谢任何帮助!!

谢谢，

桑迪普库马尔古普塔

Answer 1

似乎您按照 Thomas L. Marquardt 中的描述做了所有事情并且您甚至增加了 minWorkerThreads 和 minIoThreads。

有一篇关于 connectionManagement/maxconnection 的有趣文章可能会影响您

In general, running with default configuration works best. However, applications that have measurable latency, say latency of 100 milliseconds when communicating with a backend web service, will perform better with a few configuration changes.

然后他推荐

If your ASP.NET application is using web services (WFC or ASMX) or System.Net to communicate with a backend over HTTP you may need to increase connectionManagement/maxconnection. For ASP.NET applications, this is limited to 12 * #CPUs by the autoConfig feature. This means that on a quad-proc, you can have at most 12 * 4 = 48 concurrent connections to an IP end point.

可悲的是他补充道

If your application sees a large number of concurrent requests at start-up or has a bursty load, where concurrency increases suddenly, you will need to make the application asynchronous because the CLR ThreadPool does not respond well to these loads.