Monitoring Threads

Internet Information Server runs in a multithreaded process designed for efficient scaling on single-processor and multiprocessor systems. Threads are the objects in each process that run the process code on the processor. On single processor systems, the threads of the Internet Information Server process are switched on and off of the processor in order of priority. On multiprocessor systems, Internet Information Server can run more than one thread simultaneously.

In the Internet Information Server process, there is no simple association between threads and connections or threads and requests. Nor is there an easily quantified relationship between the optimum number of threads in the process and the number of files served, the number of requests filled, or the number of connections maintained.

The relationship between threads, connections, and requests is more complex with Internet Information Server because IIS uses the worker thread model, rather than the simpler, but less efficient, thread per client model. Instead of dedicating a thread to each connection or request, Internet Information Server dedicates one thread, the worker thread, to the task of accepting and monitoring all connections. This frees other threads to do the remaining work of the application, such as authenticating users; parsing client requests; locating, opening, and transmitting files; and managing internal data structures. As a result, several threads can service a single connection and each request from a connection might be serviced by different threads.

Even though you cannot associate individual threads and connections or requests, you can:

Count the number of threads in the Internet Information Server process.

Measure the amount of processor time each thread gets.

Associate the number of threads (and processor activity) with the number of current connections, number of files served, and other measures of server activity and performance.

Several tools monitor the threads in a process, including Process Viewer, Process Explode, PerfLog, and Performance Monitor. Individual threads are difficult to monitor, especially if they frequently start and stop. Threads are also costly to measure. Be sure to monitor the overhead (by using Process: % Processor Time) of the process in which your tool runs and subtract it from the data you collect. For a detailed discussion of this issue, see the Windows NT Workstation Resource Guide, Chapter 10, "About Performance Monitor," "Monitoring Processes and Threads."