Tips for Getting the Most Out of an 8-Processor Machine

IIS scales well up to four processors out of the box, but you will have to pay closer attention to tuning if you want IIS to scale up to an 8-processor machine. The applications that can best take advantage of more than four processors are the ones that involve heavy ASP processing and have heavy back-end SQL dependencies. When testing the Web application, keep a close eye on theSystem: Context Switch/Sec, Processor: %Processor Time, Active Server Pages: Request Execution Time, Active Server Pages: Request/Sec andActive Server Pages: Request Queued counters. If the server has excessive context switching (tens of thousands/sec) and the CPU utilization is high (>80%), then you should look into decreasing the AspProcessorThreadMax setting.

As an example: On a particular application where the optimal AspProcessorThreadMax setting was 20 on a 4-processor machine, tests showed that the same setting to optimize an 8-processor machine was 5. At this setting, the application scaled 100% when going from 4 to 8 processors.

When lowering the AspProcessorThreadMax, you should see that the Active Server Pages: Request Execution Time and System: Context Switches/Sec counters both decrease, which will in turn allow IIS to use the process time more effectively and execute more ASP requests per second. When testing this, you should make sure that there is a small and bounded ASP Queue. This ensures that all the ASP threads are actively processing ASP requests, and you will get a better feel of what the maximum capacity is for the server.

An estimate of acceptable maximum queue size can be derived by dividing the response time that we are willing to accept (e.g., 3 seconds) by the measured execution time from Active Server Pages: Request Execution Time (e.g., 200 milliseconds). The portion of the response time contributed by the server to a single request is given roughly by the queue size, Active Server Pages: Request Queued, divided by the number of ASP worker threads (AspProcessorThreadMax * #processors) times the execution time for a single request, as the requests in the queue are ahead of the request that just arrived. (The execution time is fairly constant independent of queue size if context switches/sec is not exceedingly large.) So for the example above, a queue of no more than 600 requests should be acceptable, assuming we have 40 ASP worker threads and that we are willing to accept an added delay of 3 seconds to the response time.

When scaling up, it is also increasingly important to make sure that your machine is caching optimally. (See the "ASP Caching" section.) Given the increased performance of an 8-processor computer, you are more likely to get a bottleneck in disk performance. Instead of investing in a higher-end disk sub system and more spindles, you can invest in more memory and increase the AspScriptFileCacheSize and AspScriptEngineCacheMax. IIS 5.0 can support up to 3 GB of memory, so if your content is too large for IIS to cache fully, you will still have to build out your disk subsystem.