RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Optimize ASP and IIS by Decoupling Long-running Requests

Lengthy Web requests, such as those that process and format complex reports, tie up threads from the ASP thread pool. When the number of ASP requests exceeds the number of available threads, you'll see a dramatic slowdown in response time. To solve the problem, you have to make your ASP pages run faster. And to do that you need to decouple the background request processing from the requesting ASP thread. Here's how.


here's little doubt that the Internet and the Web have transformed services and content delivery more than any other recent technology innovation. In its initial form, the Web provided a somewhat standard mechanism for delivering formatted content. As it matured, the Web was used for increasingly more complex forms of services delivery. In doing so, many developers applied traditional synchronous approaches to developing the Web systems that provided services. Synchronous delivery of these services has caused problems when attempting to scale these Web-based systems.

In this article, I will explain how synchronous access to slow and/or long running requests for resources leads to diminished Web server throughput. I used Microsoft's IIS Web server running the ASP runtime environment to address a specific problem with ASP processing. However, the general background explanation and solution you'll find here applies to all Web servers. The explanation will also include details on how to detect the problem using Performance Monitor (PerfMon). I will then describe and briefly demonstrate a solution to the problem using Microsoft's Message Queuing Server (MSMQ).

It would be grossly misleading to attempt to convince you that the solution described here will solve a majority of your Web server performance problems. Specifically, this article focuses on the unique problems caused when Web requests block for long periods of time. This problem transcends gains that can you might obtain by adding memory and increasing cache sizes, using faster processors, and (in general) spending more on better hardware. To a limited extent, scaling up (increasing the number of processors) and scaling out (increasing the number of Web servers) can help, but for a truly scalable solution that can scale orders of magnitude higher, you need to consider a different architectural paradigm.

How IIS Allocates Threads
Microsoft's Internet Information Server is optimized for relatively short-running ASP pages and/or static content. While that works well in most situations, when you combine long running requests for dynamic content with high traffic loads, the Web server's throughput can diminish rapidly. The architecture employed by IIS and ASP creates a predefined number of threads devoted to handling incoming requests. The primary issue that arises when providing synchronous access to long-running queries is that ASP's thread pool becomes a bottleneck—the volume of incoming requests outpaces the ability of ASP to process the requests.

When a Web server receives requests that it cannot process immediately, excess requests are queued up until resources are available to process the request. For IIS, you can track the queued requests using the PerfMon counter named Active Server Pages/Requests Queued. In a normally functioning Web server environment, this performance counter should stay at or very close to zero. However, as the Web server loses ground in keeping up with the volume of incoming requests, the counter value begins to grow.

To manage incoming requests, IIS allocates a pool of threads named the Asynchronous Thread Queue (ATQ). These threads satisfy most requests, including static HTML files, graphic images, and ISAPI filters/extensions. Like all other requests, ASP page requests are first triaged by the ATQ but are then turned over and serviced using a separate thread pool. The fact that IIS uses two different thread pools for ASP and non-ASP requests provides a means of troubleshooting ill-functioning Web servers.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date