ASP Request Queue

Applies To: Windows Server 2003, Windows Server 2003 with SP1

For requests to ASP pages, after the worker process picks up the request in the application pool queue, the request is sent to the Internet Server API (ISAPI) handler, which passes the request along to Asp.dll. If a thread is available, the ASP request is processed. If a thread is not available, the request waits in the ASP request queue. Requests are processed in the order in which they are received. If the ASP request queue fills to 3,000 requests (the default metabase value of AspRequestQueueMax) the server rejects the request, logs the error in the IIS log, and sends a 500 error (Server Too Busy) to the client.

If the number of queued requests is under 3,000, users with the last requests are forced to wait (called queue latency) as other requests are pulled from the queue and executed. This is an acceptable condition if the queue is cleared within a few seconds. After a few seconds, most users believe the server is not responding and click the Stop button on their Web browser. High queue latency results in poor performance for all ASP requests for the entire time the queue is saturated, because all ASP requests in a worker process share the same queue. Additionally, CPU utilization tends to spike when the queue is saturated, which results in slower response times.

You can improve ASP queuing by adjusting the default values for the AspProcessorThreadMax and AspRequestQueueMax metabase properties. AspProcessorThreadMax represents the maximum number of threads per processor, and AspRequestQueueMax represents the maximum size of the request queue. For more information about these metabase properties, see the AspProcessorThreadMax Metabase Property and AspRequestQueueMax Metabase Property.

Table 7.2 describes performance counters and their ideal values for ASP queuing. Monitor these counters in System Monitor by using a chart with one-second intervals before you change any metabase properties on your server. For more information about IIS 6.0 counters, see Performance Counters Reference.

Table 7.2 Preferred Values for Active Server Pages Queuing Performance Counters

Object\Counter Preferred or Ideal Value

Active Server Pages\Request Wait Time

As low as possible. This counter determines how long clients connecting to your site must wait before the page starts executing. If this number is high, users connected to your site might be frustrated by slow response times.

Active Server Pages\Requests Queued

As low as possible. If large queues develop, or if this number fluctuates, you might need to adjust the metabase properties that affect ASP queuing, as described in Tuning AspRequestQueueMax. This counter is not as important as the Request Wait Time counter. Queues can clear quickly, but long wait times can frustrate users connected to your site.

Active Server Pages\Requests Rejected

As low as possible. If this number is high and Requests Queued is high, you might be reaching the ASP request queue default maximum of 3,000. You might need to adjust the metabase properties that affect ASP queuing, as described later in Tuning AspRequestQueueMax.

Active Server Pages\Requests/second

Application-specific. You want this number to be as high as possible. If Requests Queued is high, this number will typically be lower. Adjusting the metabase properties that affect ASP queuing can increase it.

Processor\% Processor Time (for each processor)

Application-specific. If Requests Queued never increases and % Processor Time is low, it is likely that ASP queuing is not affecting the performance of your site.