Why request queuing is high even when request executing is below its limit?

Question

Why request queuing is high even when request executing is below its limit?

We are using below settings

• Target Framework : .Net 3.5 Framework
• Application Pool :.Net Framework v2.0.50727 with Managed pipeline mode – Integrated
• And, no of CPU is 8 so maxconcurrentRequestperCPUx8=96
• RAM : 24 GB

With Default Settings in machine.config and aspnet.config

We did testing with ACT and took performance counters.

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

ASP.NET v2.0.50727\Requests Queued

Now we made below changes

In aspnet.config

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

In machine.config

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

And provide Application Pool Queue Limit=5000 Now we have very less request queuing comparatively and high request executing as below snapshots depicts!!

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

ASP.NET v2.0.50727\Requests Queued

But surprisingly avg. response time per seconds in ACT has not improved.

So I have below questions…

1) Why there is request queuing even when request executing is below its limit (in my case no. of CPU x maxconcurrentrequestperCPU = 8 x 12 = 96)?

2) Even making changes to aspnet.config, machine.config and providing Application Pool Queue Limit=5000, why request queuing is observed?

3) Why ACT response time has not improved as Request Executing Counter is higher?

Any help is appreciated !!

Thanks,

Sandeepkumar Gupta

Answer 1

Seems like you did everything as described by Thomas L. Marquardt and you even increased minWorkerThreads and minIoThreads.

There is an interesting piece regarding connectionManagement/maxconnection which may be affecting you

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.

He then recommends

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.

And sadly he adds

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.