IIS, TCP/IP, and Incoming Requests
IIS relies heavily on TCP/IP, and you often see a lot of problems at this level. IIS sets up sockets in TCP/IP to listen for incoming requests, then initiates NT synchronization objects that notify IIS when a request comes in. One of the ATQ threads receives the request, and IIS starts processing it. From a troubleshooting standpoint, you must check the status of the network to make sure that IIS can talk to back-end servers or the clients. You can also use network traces or connection statistics.
Thread Creation and Use
Now, let's look at how IIS manages the ATQ. I don't discuss everything that goes on under the hood, but explain the parts you can affect and monitor. IIS starts with two threads in the ATQ. IIS increases the thread count as more simultaneous requests come in. IIS always tries to keep the thread count at least one thread higher than the number of current requests, assuming that this number doesn't put the thread count over the maximum that IIS allows. The default maximum number of threads is four per processor. (You set this value in the MaxPoolThreads entry in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters registry subkey.)
However, a caveat exists. Certain requests can cause IIS to increase the thread count value above the value of MaxPoolThreads for a short period of time. For example, CGI requests can cause the thread count value to temporarily increase up to 10 threads more than MaxPoolThreads. ISAPIs can also temporarily increase the count value. By default, ISAPI requests can increase the pool size by 2 times the number of megabytes of RAM in the machine with a minimum of 64 threads and a maximum of 256 threads. Although you can use the PoolThreadLimit registry value to override this value, I recommend that you change it only in extreme circumstances because changing the value can adversely affect performance.
Let's look at a few examples that will help illustrate what's happening. Let's say you're running on a one-processor machine with 256MB of RAM. Your default value for the maximum number of threads is 1 * 4, or 4; the value for your absolute thread limit is 2 * 256 = 512, which is greater than 256, so you set the thread count to 256. Assume that in all of these cases, you're at your default two threads and you haven't handled any incoming requests. Now, picture these scenarios:
- Five simultaneous .htm requests come in. The ATQ increases to four threads, and IIS delays the fifth request until one of the other four requests is complete.
- Five simultaneous CGI requests come in. The ATQ can increase the pool size temporarily, so you create six threads and handle all five requests.
- Fifteen simultaneous CGI requests come in. The ATQ can create 10 threads more than your maximum of four, so IIS handles 14 requests. IIS delays the 15th request until one of the other requests finishes.
- Thirty simultaneous ISAPI requests come in. The absolute limit for the ATQ is 256, so you can handle all 30 requests simultaneously.
- Three .htm requests and one CGI request come in, then a fourth .htm request comes in. IIS handles all five requests. When the CGI request comes in, you can increase the thread count to five, which makes room to handle the fourth .htm request.
- Three .htm requests and one CGI request come in, then two more .htm requests come in. IIS delays the last .htm request. When the CGI request comes in, you can increase the thread count to five, which makes room to handle the fourth .htm request. However, because the fourth .htm request can't increase the count any further, you can't create a sixth thread.
- Two hundred seventy ISAPI requests come in. The ATQ thread count goes to 256, and IIS delays the remaining requests.
Remember that this increase in the thread count value is temporary. Therefore, when IIS finishes handling the requests, the thread count value goes back down.
Now, let me throw a wrench in the works. The thread count doesn't go down right away. The value that increases and decreases is MaxPoolThreads. The ATQ uses a hard-coded internal algorithm to create and destroy threads, which it does based partly on the value of MaxPoolThreads. So, in the previous scenarios, all you really did was change this value. IIS then decided to change the actual thread count. When the requests are complete, you lower the value, but IIS doesn't immediately decrease the actual number of threads. In fact, the Time to Live (TTL) of an inactive ATQ thread is 24 hours, which means that if you handle 30 ISAPI requests and IIS increases the thread pool count to 31, for the next 24 hours, you could handle 31 simultaneous .htm requests because the threads already exist.
Because of the long TTL of threads, IIS reuses threads in the pool, starting with the most recently used and working backward. Thus, if you have 31 threads and for the next 24 hours you have at most 16 requests at a time, IIS can terminate 15 threads.
Next Month
In each of the next articles in this troubleshooting series, I'll concentrate on one specific type of problem and how you can locate the problem to resolve it. I'll constantly reference information in this article and also introduce more architecture information as needed. Next month, I'll start showing you how to apply the knowledge you've gained this month to isolating and fixing problems you might encounter.
Note: IIS handles all static requests (e.g., .htm, .jpg) in the inetinfo.exe process regardless of which isolation setting the application housing the requested object has.
Note: All values I discuss here are IIS default settings. To change these settings, please refer to the Microsoft articles "The Art and Science of Web Server Tuning with Internet Information Services 5.0" (http://www.microsoft.com/technet/iis/iis5tune.asp) or "Internet Information Server 4.0 Tuning Parameters for High-Volume Sites" (http://www.microsoft.com/technet/iis/technote/iistun.asp), or go to http://www.microsoft.com/technet/iis/maintain.asp.
Note: The actual thread count isn't what changes but rather the value you use to set the thread count. The value might go up or down, but IIS doesn't immediately change the actual thread count.