Diagnosing Problems in IIS

In "IIS Exception Monitor," November 1999, Ken Spencer wrote about using Microsoft IIS Exception Monitor to diagnose problems in IIS 4.0. IIS-related problems have become more complex, and administrators must know a lot more to diagnose them. This month, I show you several new techniques and tools that you can use to isolate and resolve IIS problems. The techniques I describe are the same techniques I use every day when I'm working with customers to solve their IIS problems. I give you a brief introduction to IIS's architecture, then offer tips, tricks, and things to remember about troubleshooting IIS. (If you want to delve into the core Windows NT information I provide, start with the resources I list in the sidebar "Support Extras," page 2.)

How IIS Works
The IIS WWW services run in processes based on the server settings and OS version. The processes that the WWW services can use are

• inetinfo.exe—This process is the core IIS process for both Windows 2000 and NT 4.0 and hosts the WWW service (w3svc), FTP service (msftpsvc), SMTP service (smtpsvc), News service (nntpsvc), and more.
• mtx.exe (NT only)—This process is the Microsoft Transaction Services (MTS) machine's process for hosting Out-Of-Process (OOP) Web applications or Modular Transactional System (MTX) server packages. A separate MTX process exists for each OOP application.
• dllhost.exe (Win2K only)—COM+ objects use this process to host all OOP Web sites, both pooled OOP and isolated OOP. One dllhost.exe process exists for the pooled applications, and one exists for each isolated OOP application.

When you're using tools to monitor a process, keep in mind all the processes that can be involved. Also, remember that by default, IIS 5.0 runs all Web sites in the pooled OOP process.

IIS, ASP, and Threading
IIS uses a pool of threads (i.e., instances of code execution) to handle incoming requests and work on those requests. This pool of threads is called the Asynchronous Thread Queue (ATQ). IIS uses a thread pool because reusing an existing thread is faster than making a new thread each time a new request comes in. The ATQ initially handles all incoming requests. After the initial handling, IIS might send the request to another queue or leave the request in the ATQ. Here's a list of request types and the queue in which they run:

• .htm, .jpg, .gif, and other static requests always run in the ATQ.
• A Common Gateway Interface (CGI) request creates a new process to handle the request and run in that process. However, by default, the request still holds the ATQ thread it started in to handle the return information from the CGI process.
• Internet Server API (ISAPI) filters or extensions by default run in the ATQ. However, an ISAPI component can create its own thread pool and use that pool for execution.
• Active Server Pages (ASP) requests are passed from the ATQ to the thread pool that ASP uses (a COM+ thread pool in IIS 5.0 or an MTX pool in IIS 4.0).
• OOP requests (i.e., OOP applications) go to the thread pool that ASP uses. The ASP thread makes the appropriate interprocess call to the OOP application.

Keep this information in mind when you're troubleshooting a hung system or a nonresponding server. If no ASP files are responding but you can open an .htm page, start looking specifically at which ASP requests are running. If IIS won't serve .htm pages, start your troubleshooting by looking at the whole server instead of just ASP. (ASP might still be the cause of the problem, but you need to get the whole picture first.)

NT Synchronization Objects
IIS relies heavily on NT synchronization objects for efficiency. An NT synchronization object lets a running thread put itself to "sleep" while it waits for information, which is important in a multithreaded application such as IIS. For example, in a multithreaded OS, the OS lets each running thread have a certain amount of time to run, then the OS saves the thread's state and lets the next thread in line run (based on priorities). The OS essentially cycles through all the threads that it's letting run. (Note that this overview is very simplistic. The actual way in which NT selects what thread will run next is much more complex.)

The swapping of one thread for another is called context switching, which NT Performance Monitor can measure. The default amount of time a thread can run varies based on processor type, the OS (e.g., NT Server, NT Workstation), and the priority of the thread. For this example, I use a middle-of-the-road value—2700 microseconds.

A user calls up a Web page that goes to a back-end server and retrieves stock quotes. The Web page then takes that information and sends a page with the requested data back to the client. The time it takes to get the stock information might be about 1 second, which seems like an eternity compared with the 2700 microseconds per context switch. So, instead of having the thread stay in the rotation when you know the thread won't be doing anything for a long time, you can take the thread out of the rotation and let NT tell you when the data you're waiting for has come back. Taking the thread out of rotation allows more time for other active threads to work; it also reduces the number of context switches, which can save time and processing overhead. Synchronization objects perform this task.

Because of NT's ability to use synchronization objects and because IIS is usually retrieving data from somewhere for most requests (and this retrieval is always longer than the context time), you can assume that at any given time, most of IIS's worker threads (both ATQ and ASP) will be out of the rotation, or asleep. Therefore, you can often see a lot of threads on an IIS server but still have low CPU utilization.

   Previous  [1]  2  Next