Udostępnij za pośrednictwem

“ASP.NETRequests Queued” bug in IIS integrated Mode.

  • Artykuł

Introduction.

There was a bug in ASP.Net 2.0 in which the “ASP.NET\Requests Queued” performance counter only reported values when a request was queued in the ASP.Net Queue. It didn’t count the requests that were waiting for the CLR thread pool. This was only in IIS7+ integrated mode and was different than the behavior in classic mode.

The problem is fixed now in ASP.Net 4.0, so if you were monitoring the counter before, you might start seeing values and worry about the performance of your application, when this behavior is expected. A patch for 2.0 was also released in KB979917. The problem was discovered by the SharePoint team who uses the counter to monitor the health of their sites. Also, updates released after this KB should contain the fix.

More Details.

Request for ASP.Net are always delivered first in the context of an IIS thread. At that point, ASP.Net queues a work item to the CLR thread pool and returns, so IIS can use this thread to process another request. Once the CLR thread pool decides to activate this work item, the request continues on the context of a CLR worker thread. It could take some time until the thread pool activates the requests, so these acts as a queue of request. Next, we monitor if we have too many concurrent request, and might decide to put the request in the ASP.Net queue

This behavior is very similar in both classic and integrated mode. The main difference is that in integrated mode there is a single queue for the whole app pool, while classic mode has a queue in each app domain. Also different is the settings used to configure those queues. None of these details are relevant to this discussion. Tmarq has blogged about this.

The point is that “Requests Queued” needs to be incremented just before queuing the work item to the CLR thread pool and decremented just after the work item started to run in the worker thread. If the request is then stored in the ASP.NET queue, the counter needs to be incremented once more, and decremented when it is finally removed from the queue and scheduled to be executed. This was done that way in classic mode, but in integrated mode we were only doing the second increment/decrement.

In conclusion:

The immediate effect of the bug was that the same application, under the same load, could show values on the counter in classic mode, but showed zero if moved to integrated mode. This is now fixed. On the other hand, customers that always used integrated mode might start to see values in this counter when moving to 4.0 (or applying the patch for 2.0) and be concerned, trying to find a performance issue that doesn’t exist. This is the main reason of this article. Hopefully, our customers will find it helpful.

Additional Resources

Other performance related articles: https://blogs.msdn.com/josere

Comments