Monitoring and Tuning Your Server

Tuning the ASP Queue and Thread Pool

There have been significant changes in the handling of ASP queuing and related caching issues in IIS 5.0 relative to IIS 4.0:

In IIS 4.0, the IIS Template Cache limit was set to -1 (that is, unlimited). In IIS 5.0 it is set to 256 files. You can, and almost certainly should, adjust this to suit your Web site’s requirements, but do not set it to zero. For an explanation, see below, “How This Affects Server Administration.”
In IIS 4.0, the IIS Script Engine Cache limit was set to 30 files. In IIS 5.0 it is set to 120. As with the IIS Template Cache, you can change this limit.
In IIS 4.0, ProcessorThreadMax was in the registry, and was set to 10. Administrators routinely changed this value themselves as needed. In IIS 5.0, the setting has been moved to the metabase, is set to 25, and is handled automatically.
In IIS 4.0, the Request Queue length was set to 500 by default. In IIS 5.0, it is set to 3,000. You probably won’t need to change this setting, but you can if you need to. In addition, you can use Custom Errors. There is also automatic client-connection testing so that an ASP page is processed and the output sent only if the client is still connected. (Unfortunately, many proxy servers keep the connection alive even if the client cancels it, defeating the purpose of this test.)

How This Affects Server Administration

With the IIS Template Cache limit set to -1, as it was in IIS 4.0, this cache could grow arbitrarily large. On Web sites with lots of ASP content, the IIS Template Cache tended to fill all of the RAM in the server. In contrast, this limit in IIS 5.0 is set by default to 256 files. Because each site has its own requirements, you should reset the limit to meet your site’s particular needs.

Perhaps the easiest way to accomplish this is to monitor performance as you increase and decrease the value. Because an entry in this cache can point to one or more entries in the IIS Script Engine Cache, and because best performance occurs if the scripts in ASP pages are found in the IIS Script Engine Cache, you should never set the limit on the IIS Template Cache to zero. (Doing so prevents any hits on the IIS Script Engine Cache, because the IIS Script Engine Cache entry for a particular .asp file can only be referenced through its template. Thus, if the template for it is not cached, by definition, the IIS Script Engine Cache is rendered useless.) IIS Script Engine Cache hits provide better performance than hits on the IIS Template Cache, so if you make IIS Script Engine Cache hits impossible, performance suffers badly unless all your pages are static.

To monitor the IIS Template and Script Engine Caches, use the following counters in PerfMon: Active Server Pages: Templates Cached, Active Server Pages: Template Cache Hit Rate, and Active Server Pages: Script Engines Cached.

IIS 5.0 includes a mechanism that effectively adjusts the value of the ASPProcessorThreadMax metabase entry “on the fly” (the actual value is not changed). When processor utilization drops below 50 percent, which indicates that threads are blocked (perhaps while waiting for an external database to return the results of a query), IIS 5.0 increases the number of active threads so that other requests can be serviced in a timely manner. When processor utilization exceeds 80 percent, indicating a relatively unblocked situation, IIS 5.0 deactivates threads to reduce the amount of context switching. Both lower and upper bounds are settable; 50 percent and 80 percent are the default values.

You can still change the length of the ASP Request Queue if you need to, and you can use Custom Errors to return friendly messages if your server becomes too busy to handle all current requests. Remember that a custom “Server Too Busy” error message is returned only when the length of the queue is at its maximum and another request comes in. (For information about creating custom error messages, see the IIS 5.0 online product documentation.)

In sum, a lot of the tweaking that was necessary in IIS 4.0 is performed automatically in IIS 5.0, thus reducing the workload on server administrators. But administrators can still change settings to accommodate specific conditions they encounter on their servers.