Request | request processing ASP Request
Figure 1 illustrates a typical processing process for an ASP request. The request is initialized by the WAM object. The WAM object then sends it to Asp-runtime. Asp-runtime responds to it by creating an internal Page object.
The WAM object is a free thread object. When it invokes an ISAPI extension such as ASP.DLL, it uses the thread of the MTA model that is assigned by the thread pool maintained by Iis-runtime.
One tricky question when creating an ISAPI extension is how to handle the problem of thread concurrency and synchronization brought about by this MTA thread pool. Asp-runtime simplifies the problem by switching each ASP request to a single apartment (STA) before running ASP scripts. Asp-runtime manages a separate STA secondary thread pool (in the background, ASP actually implements this by using the COM + thread pool). ASP architects created this thread pooling scheme to provide an optimal balance between concurrency and resource utilization, while eliminating the need to synchronize programmers.
Figure 1
Figure 2 illustrates how asp-runtime switches each request from an MTA thread to an STA thread. The Asp-runtime scheduling mechanism puts each request into a central request queue. An STA thread in a thread pool managed by ASP monitors the queue and processes the request in a first-in, first-out manner. Note that the size of this thread pool is dynamically changing. Asp-runtime generates additional threads during peak traffic and frees threads when there is less traffic.
Figure 2
Switching to an STA thread effectively solves the concurrency problem, but it also has a significant impact on performance. An ISAPI extension DLL that handles each request in a separate MTA thread squadron can provide faster response times.
IIS provides a way to set the maximum size of the STA thread pool and request queue. The size of the thread pool is controlled by the AspProcessorThreadMax primary key in the IIS metabase. The default setting for this primary key is 25 per processor (comments: This number is best found in Microsoft's documentation to prove it.) Some say the number is 10/cpu. In other words, in a four-processor computer, each process that processes an ASP can have up to 100 worker threads. You should avoid changing the key value unless the problem with the adjustment thread pool is considered mature. Note that you cannot use Internet Server Manager to change this setting. You must use a management script or a VB application to modify it.
IIS sets a maximum capacity for ASP request queues. By default, Asp-runtime allows queues to hold up to 3,000 requests (another Microsoft document indicates that this queue can hold only 500 requests). Once it is exceeded, the incoming ASP request is rejected, and the error message is "Server Too Busy".
You can use IIS Management Objects and ADSI to programmatically modify AspProcessorThreadMax primary keys and AspRequestQueueMax primary keys. For example, in a Standard EXE project, refer to the active DS type library and write the following code:
Dim MyWebServer as Activeds.iads
Set mywebserver = Getoject ("Iis://localhost/w3svc")
Mywebserver.put "AspProcessorThreadMax", 30
Mywebserver.put "AspRequestQueueMax", 1500
Mywebserver.setinfo
Here's a quick summary of how the ASP thread pool works in IIS that is installed by default on a single-processor computer. The thread pool is available for 25 STA worker threads per processor. When a request arrives, it is placed in the request queue, and Asp-runtime dispatches an idle STA thread from the thread pool, if one is available (note that this scenario allows any thread in the thread pool to handle the request). If there are no free worker threads, the request joins the queue. All requests are processed as long as the queue does not reach the default maximum capacity.
"Programming distributed Application with Visual Basic 6.0" from Ted Pattison
