Slow IIS Performance

I'm running IIS 4.0 and Windows NT 4.0 with Service Pack 6a (SP6a) on a 733 MHz dual-processor system. IIS seems to be running slowly. I've used Performance Monitor to check the disk, memory, processor, and network subsystems, and I haven't found anything unusual. What's causing IIS's slow performance?

When I received this inquiry from a Web hosting company, I thought it unusual that Performance Monitor didn't detect anything odd. Some situations can appear normal unless you know where to look. So, I had my client check a couple of CPU counters again to test a theory. He reported the following information:

%Processor Time (the Average counter): 11% DPC Time: 60

A deferred procedure call (DPC) is an interrupt that requires the processor's attention, which can be delayed while the processor attends to other, more important tasks. A high number of DPCs can indicate that a hardware subsystem, such as a NIC or a drive, isn't performing well. A high number can also indicate poor task allocation in a multiprocessor environment.

In this case, however, a CPU at an average use of 11 percent isn't busy doing anything important. This percentage indicates that interrupts are being generated but for some reason can't be completed. That is, whatever is trying to occur is being blocked. Blocking usually occurs when a Web application issues a call to a component or connector, such as a database query, and that call takes a while to process. In the meantime, the system resource (in this case, a thread) that made the call is waiting for that task to complete before it can resume. In such a situation, processor use is low while queue figures are high because requests get stacked up.

The job is to find out where the choke point is and relieve it. A common mistake is to beef up the system by adding more memory or more CPUs. However, because the choke point isn't addressed, enhancing the system only makes matters worse because it increases the number of requests without delivering more capacity.

In the case of DPCs, troubleshooting high DPC time is more complex in multiprocessor systems. In some systems, DPCs can stack up on one processor and slow the entire system. By analyzing each processor's activity, you can determine whether DPC interrupts are being symmetrically distributed or assigned to one processor.

If the %Processor Time number is high and the % DPC Time number is greater than 50 percent on that processor, you can benefit from upgrading to a system board that distributes DPC interrupts. If NICs are generating the DPC interrupts, you might be able to spread the load by adding more NICs because each card's processing is usually assigned to a different CPU in a multiprocessor system. You can also make a registry change that lets Windows 2000 or NT distribute DPCs to the least-used processor. (For more information about this registry change, see the Microsoft article "MS Windows NT Server 4.0 Enterprise File Server Scalability and Performance" at http://www.microsoft.com/technet/winnt/winntas/technote/implemntintegra/fsscale.asp. In addition, the Microsoft article "How to Install and Use the Interrupt-Affinity Filter Tool" at http://support.microsoft.com/support/kb/articles/q252/8/67.asp has a processor-interrupt affinity tool for Win2K available for download.)

To resolve this situation, I studied NTFS permissions on the databases in use. Certain files had incorrect permissions that resulted in access errors. By resetting these permissions, I reduced DPC time to an acceptable range.