The combination of the new HTTP.sys kernel mode driver and the use of worker processes to actually handle requests has led to a number of enhancements to the overall performance of the system. We've already looked at many of these here and in earlier chapters.
Overall, the benefits of the new execution model and the worker process system account for more than 80% of the performance improvements in the system. Microsoft predicts a 100% performance increase for most sites when moving to the new model on an 8-way multiprocessor machine.
To make the best use of the new architecture, we need to make the best use of the application pool system. Two systems can help improve the overall quality of the worker process system?Web gardens and CPU affinity.
Web gardens are where you configure a single application pool to use more than just one worker process to handle requests. Modern processors are capable of doing more than one thing at the same time, but you need to be careful about how you configure Web gardens, based on the sites and server you are supporting.
The major benefits from Web gardens only really become apparent on systems with multiple CPUs. For example, in a system configured with only one application pool and one processor, you are unlikely to gain any benefit from using multiple worker processes.
In a two-way SMP system with only one application, you will be able to increase overall throughput by starting two worker processes, one for each CPU, where you will obtain a potential 100% increase in throughput by allowing both processors to process requests.
In the same two-way SMP system with two application pools, you could configure each pool with only one worker process?one for each CPU.
The reality, of course, is that even one worker process is probably not going to saturate your CPU. So many other factors?that is, waiting on data, disk access, and responses from a remote database? mean that a single worker process on even a single processor machine will never achieve its full potential.
Therefore, setting up a Web garden needs careful monitoring of the load on the server to determine how much CPU availability there is and what the limits are for the hardware in question. The more dynamic elements (ASP/ASP.NET) you have in your sites, the more likely you are to benefit for multiple worker processes.
For more information on monitoring the performance of IIS, go to Delta Guide series Web site at www.deltaguideseries.com and enter article ID# A020501.
WORKER PROCESS SETUP
Generally, I prefer to use at least two worker processes for each application pool, mostly to provide an up-and-running backup worker process in case of a problem with the other one. I've actually found that I get the best performance out of a PIII 833MHz, dual-processor machine when I have eight active worker processes handling a site that is about 50/50 static and template data.
CPU affinity is connected to the idea of Web gardens. It enables you to assign a particular application pool to be executed on only one CPU. You can use this to evenly spread your worker processes across your CPUs or to make use of specific functionality in a CPU for particular tasks. For example, a heavy computational process will execute faster on a processor with more level 2 cache than a similarly rated companion.
As an extension of this, IIS 6 has been written with processor affinity in mind, which means that it can take advantage of the single-CPU execution model to get the best performance out of applications. It does this by using the facilities within the CPU to keep as much information as possible within the CPU cache and through the use of consistent registers within the CPU to help increase performance.
This also helps retain the increase in speeds experienced as you raise the number of processors. Instead of spreading the load out across each CPU as it's added to the system, processes continue to run within the confines of their own processor. Additional processors are therefore freely available for additional worker processes.
To set processor affinity, you must set an affinity mask on the application pool to define which processors the application pool can be executed on. To do this, first set the SMPAffinitized property within the metabase. Then set the value of the SMPPRocessorAffinityMask for each application pool. A value of 0 indicates that the pool can execute on any processor.
BE CAREFUL WITH PROCESSOR AFFINITY
If you decide to set processor affinity, be sure that other administrators in your organization are aware of your new configuration. That way, they won't mistakenly reconfigure IIS or other applications and mess up your manual balance of the processors' workload.