IIS 6.0 employs a new process model. A kernel mode HTTP listener (Http.sys) receives and routes HTTP requests (and can even satisfy requests from its response cache). Worker processes register for URL subspaces, and Http.sys routes the request to the appropriate process (or set of processes, in the case of application pools).
Figure 4 shows the difference between the IIS 5.0 and IIS 6.0 process models. IIS 5.0 uses WinSock to accept connections on port 80. Requests are received by the inetinfo process, which then either executes the request in-process, or hands it to a dllhost process for out-of-process handling (to provide isolation). The response is sent back by the inetinfo process.
Figure 4 Process Models for IIS 5.0 and IIS 6.0
The IIS 6.0 process relies on the kernel-mode Web driver, Http.sys. In the new model, Http.sys is responsible for connection management and request handling. The request may either be served from the Http.sys cache or handed to a worker process for further handling (see Figure 5). Multiple worker processes may be configured, providing isolation at lower cost.
Http.sys includes a response cache. When a request matches an entry in the response cache, Http.sys sends the cache response directly from kernel-mode. Figure 5 shows the request flow from the network through Http.sys (and possibly up to a worker-process).
Figure 5 Request Handling in IIS 6.0
Because a Web server has a kernel-mode as well as a user-mode component, both must be tuned for optimal performance. Therefore, tuning IIS 6.0 for a specific workload includes configuring:
· Http.sys (the kernel mode driver) and the associated kernel-mode cache.
· Worker processes and user-mode IIS, including application pool configuration.
Additionally, some tuning parameters that affect performance are discussed in the following sections .
Kernel-mode Tunings
Performance-related Http.sys settings fall into two broad categories: cache management, and connection and request management. All registry settings are stored under the following entry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters
If it is already running, the HTTP service must be stopped and restarted for the changes to take effect.
Cache Management Settings
One of the benefits that Http.sys provides is a kernel-mode cache. If the response is in the kernel-cache, it is possible to satisfy an HTTP request entirely from kernel-mode, which significantly lowers the CPU cost of handling the request. However, the kernel-mode cache of IIS 6.0 is a physical-memory based cache, and the cost of an entry is the memory it occupies.
An entry in the cache is of benefit only when used. However, the entry uses physical memory at all times, whether the entry is in use or not. The usefulness of an item in the cache (the difference being able to serve it from the cache makes) and its cost (physical memory occupied) over the lifetime of the entry need to be evaluated taking into account the resources available (CPU, physical memory) and the workload requirements. Http.sys attempts to keep only useful (actively accessed) items in the cache, but it is possible to increase the performance of the web server by tuning the Http.sys cache for particular workloads.
Below are some useful settings for the Http.sys kernel-mode cache:
· UriEnableCache. Default Value: 1. A non-zero value enables the kernel-mode response and fragment cache. For most workloads, the cache should remain enabled. Consider disabling the cache if you expect very low response and fragment cache utilization.
· UriMaxCacheMegabyteCount. Default Value: 0. A non-zero value specifies the maximum memory available to the kernel cache. The default value, 0, allows the system to automatically adjust the amount of memory available to the cache. Note that specifying the size only sets the maximum, and the system may not allow the cache to grow to the specified size.
· UriMaxUriBytes. Default Value: 262144 bytes (256 KB). This is the maximum size of an entry in the kernel cache. Responses or fragments larger than this will not be cached. If you have enough memory, consider increasing this limit. If memory is limited, and large entries are crowding out smaller ones, it may be help to lower this limit.
· UriScavengerPeriod. Default Value: 120 seconds. The Http.sys cache is scanned by a scavenger periodically and entries not accessed between scavenger scans are removed. Setting the scavenger period to a high value reduces the number of scavenger scans. However, the cache memory usage may grow as older, less frequently accessed entries are allowed to stay in the cache. Setting this period to too low a value causes more frequent scavenger scans, and may result in excessive flushes and cache churn.
Request and Connection Management Settings
Http.sys also manages inbound HTTP/HTTPS connections and is the first layer to handle requests on these connections. It uses internal data structures to keep information about connections and requests. Although such data structures can be created (and freed) on demand, it is more CPU-efficient to keep some in reserve in look-aside lists. Keeping such reserves help Http.sys handle fluctuations in load with less CPU usage. Note that load fluctuations are not necessarily the result of fluctuations in externally applied load. Internal optimizations to promote batch processing, and even interrupt moderation may result in load fluctuations and spikes.
The reserves help reduce CPU usage and latency, and increase Web server capacity but increase memory usage. When tuning the request and connection management behavior of Http.sys, it is important to keep in mind the resources available to the server, performance goals, and the characteristics of the workload. Use the following request and connection management settings:
· MaxConnections. This value controls the number of concurrent connections Http.sys will allow. Each connection consumes non-paged-pool, a precious and limited resource. The default is determined quite conservatively to limit the amount of non-paged-pool used for connections. On a dedicated web server with ample memory, the value should be set higher if a significant concurrent connection load is expected. A high value may result in increased non-paged-pool usage, so care should be taken to use a value appropriate for the system.
· IdleConnectionsHighMark, IdleConnectionsLowMark, and IdleListTrimmerPeriod. These values control the handling of connection structures not currently in use: how many must be available at any time (to handle spikes in connection load), the low and high watermarks for the free list, and the frequency of connection structure trimming and replenishment.
· RequestBufferLookasideDepth and InternalRequestLookasideDepth These values control the handling of data structures related to buffer management, and how many are kept in reserve to handle load fluctuations.
User-mode Settings
IIS Registry Settings
The following registry settings are found under this entry:
HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters\
· MaxCachedFileSize (REG_DWORD) in bytes. Allows file sizes up to the specified size to be cached (default 256 KB). The actual value depends on the number and size of the largest files in the dataset versus the available RAM. Caching large, frequently requested files can reduce CPU usage, disk access, and associated latencies.
· MemCacheSize (REG_DWORD) in MB. Limits the IIS user-mode cache size to the specified size (default is adjusted by IIS depending on available memory). Choose the value carefully based on the size of the hot set (set of frequently accessed files) versus the amount of RAM or the IIS process address space, which is normally limited to 2 GB.
· DisableMemoryCache (REG_DWORD). Disables the user-mode IIS cache when set to 1 (default is 0). When the cache hit rate is very small you can disable the cache altogether to avoid the overhead associated with the cache code path.
· MaxPoolThreads (REG_DWORD). Sets the maximum number of pool threads that can be created per processor (default 4, range unlimited). Each pool thread watches for network requests and then processes them. The MaxPoolThreads count does not include threads that are currently processing ISAPI applications. This parameter should be increased if the CPU shows sub-optimal average usage because all existing threads are busy and there is no available thread to process new requests.
· PoolThreadLimit (REG_DWORD). Sets the maximum number of pool threads that can be created in the system (default is four times the number of processors, range unlimited). PoolThreadLimit must be greater than or equal to MaxPoolThreads. Normally PoolThreadLimit = MaxPoolThreads ´ number of processors. Setting only one of these parameters is sufficient. If both MaxPoolThreads and PoolThreadLimit are specified, the more stringent limit is used.
· ObjectCacheTTL (REG_DWORD) in seconds. Controls the length of time that objects are allowed to stay in the IIS user-mode cache without being accessed (default 30 seconds, 0xFFFFFFFF disables the object cache scavenger thread). This parameter can be increased if there is no memory pressure on the system and if the content being served does not change frequently. Lower the parameter if the system is under memory pressure and the user-mode cache is growing. See also ActivityPeriod later in this section.
· ActivityPeriod (REG_DWORD) in seconds. Allows a file to be cached only if it was hit repeatedly within the activity period (default 10 seconds, a value of zero will disable this check). This parameter reduces caching overhead caused by caching files that are not accessed frequently You can increase the activity period if the cache is not under heavy churn and there is enough free memory, or you can decrease the activity period if there is a heavy request load on the cache.
· DataSetCacheSize (REG_DWORD) default 50. Sets the maximum number of virtual directory entries in the metabase dataset cache. Increase if the number of installed virtual directories exceeds the default. The impact of an under-sized dataset cache is increased latency (accompanied by reduced throughput and low CPU usage) when serving static content.
IIS Metabase
The following settings are found under W3SVC/.
· AspMaxDiskTemplateCacheFiles. Allows disk caching of ASP script templates. Compiling the ASP templates is a processor-intensive task. Memory constraints limit the number of templates that can be cached in-memory. Fetching compiled templates from the disk template cache incurs less cost than compiling templates that do not fit into the ASP memory cache. See also AspScriptEngineCacheMax later in this section.
· AspDiskTemplateCacheDirectory. If possible, set to a platter not in heavy use (for instance, not shared with the operating system, pagefile, IIS log or other frequently-accessed content). The default directory is “%windir%\system32\inetsrv\Template Disk cache\ASP Compiled Templates”.
· AspScriptEngineCacheMax. Set to as many script engines as memory limits allow (default 125).
· AspScriptFileCacheSize. Set to as many ASP templates as memory limits allow (default 250). See also AspMaxDiskTemplateCacheFiles earlier in this section.
· AspExecuteInMTA. Set to 1 (enable) if errors or failures are detected while serving some of the ASP content. This can happen, for example, when hosting multiple isolated sites where each site runs under its own worker process. Errors are typically reported from COM+ in the event viewer. This setting enables the multithreaded apartment model in ASP (the default 0 means disable).
· AspProcessorThreadMax. Increase if the current setting (default 25) is not sufficient to handle the load (possibly resulting in errors serving some requests)
· CentralBinaryLoggingEnabled. Enable central binary logging by setting this parameter to TRUE. Binary IIS logging reduces CPU usage, disk I/O and disk space usage. Central binary logging is directed to a single file, in binary format, regardless of the number of hosted sites. Parsing binary-format logs requires a post-processing tool.
IIS Worker Process Options (IIS Admin UI, Application Pool Properties)
The options for recycling IIS worker processes under the IIS Admin UI provide practical solutions to acute situations or events without the need for administrator intervention, service reset, or even computer reset. Such situations and events include memory leaks, increasing memory load or non-responsive or idle worker processes. Under normal conditions, recycling options may not be needed and can be turned off (or the system can be configured to recycle very infrequently). In the following sections, bold names are per-app-pool variables. When using scripts to set these variables, use the path /LM/W3SVC/AppPools/n, where n is the application pool index.
There are three options, as the following tables describe:
· Recycling options. These are found on the Recycling tab.
· Performance options. These are found on the Performance tab.
· Worker process health monitoring options. These are found on the Health tab.
Table 8. Recycling Options
|
Parameter |
Description |
|
PeriodicRestartRequests, DWORD, option disabled by default, default value 35000 |
Periodic recycling based on time |
|
PeriodicRestartRequests, DWORD, option disabled by default, default value 35000 |
Periodic recycling based on the (cumulative) number of requests |
|
PeriodicRestartSchedule, MULTISZ, disabled by default, empty string value |
Recycling at given time settings |
|
· (PeriodicRestartMemory, DWORD, default value 512 MB · PeriodicRestartPrivateMemory, DWORD, default value 192 MB
|
Memory-based recycling (disabled by default) allows recycling of a worker process if it has reached either: · A maximum amount of virtual memory · A maximum amount of used memory Under continuously growing memory pressure it could be helpful to allow frequent recycling of worker processes based on a tight-memory criterion, using either or both of these parameters. |
Table 9. Performance Options
|
Parameter |
Description |
|
IdleTimeout, DWORD, in minutes, default 20 |
Shut down a worker process after being idle for more than a specified amount of time. This can save some resources on limited-memory systems but it is not recommended in situations that will require frequent spawning of new worker processes under heavy CPU load, because of the overhead associated with process creation. |
|
AppPoolQueueLength, DWORD, default 2000 |
Limit the kernel request queue length per App-Pool. Requests consume paged-pool, and this limit should be lowered under high demand for paged-pool. Exceeding the designated length will cause the server to reject the request with a non-customizable error 503. |
|
CpuAccounting, BOOLEAN, disabled (0) by default, 1 for enabled |
Monitor CPU usage. You can set the maximum CPU use by percentage (CpuLimit, DWORD, default 0) and the refresh period to monitor it in minutes (CpuResetInterval, DWORD, default 0). The options upon reaching the CPU usage limit are to take no action (but write an event to the event log) or to shut down the worker process (CPUAction, DWORD, default 0 for “No action”, maximum 1 for “Shutdown Worker Process”). |
|
MaxProcesses, default: 1 worker process to handle all requests |
You can control the total number of worker processes in Web Garden mode of operation. In Web Garden mode, several worker processes handle the request load under a single application pool. There is no pre-assignment of worker processes to Web sites via different app-pools. In some cases one worker process is not enough to handle the load (indicated by poor CPU usage and long response times) and increasing the number of worker processes may improve throughput and CPU usage. One case where Web Garden mode may be considered is with hosting multiple sites. Multiple worker processes can also offer more reliability in case of an incidental crash of one of them, with little chance of total service disruption. Web garden mode is easier to set up and control than multiple pre-assigned application pools. |
Table 10. Health Options
|
Parameter |
Description |
|
PingingEnabled, BOOLEAN, default 1 PingInterval, DWORD, default 30 seconds |
Pinging worker processes (PingingEnabled) periodically (PingInterval). If not responding, the worker process is considered to be in a bad state and IIS will attempt to terminate it and spawn another. |
|
RapidFailProtection, BOOLEAN, default RapidFailProtectionMaxCrashes, DWORD, default 5 failures RapidFailProtectionInterval, DWORD, default 5 minutes |
Control a rapid failure rate situation (RapidFailProtection) by setting the maximum number of failures allowed (RapidFailProtectionMaxCrashes) within a given time span (RapidFailProtectionInterval). If such a rate of failures is recorded the application pool will be disabled, and will write related event log messages. |
|
StartupTimeLimit, DWORD, default 90 seconds |
Control the worker process startup limit period before considering it a failure |
|
ShutdownTimeLimit, DWORD, default 90 seconds |
Control the worker process shutdown limit period before considering it nonresponsive. |
Secure Sockets Layer Tuning Parameters
Secure Sockets Layer (SSL) use imposes extra CPU cost. The most expensive component of SSL is the session establishment cost (involving a full handshake), then reconnection cost and encryption/decryption cost. For better SSL performance, do the following:
· Enable keep-alives for SSL sessions. This eliminates the session establishment costs.
· Reuse sessions when appropriate (especially with non-keep-alive traffic).
· Note that larger keys provide more security but also use more CPU time.
· Note that not all components of your page may need to be encrypted. However, mixing plain HTTP and HTTPS may result in a pop-up warning on the client-browser that not all content on the page is secure.
ISAPI
No special tuning parameters are needed for ISAPI. If writing a private ISAPI extension, make sure to code it efficiently for performance and resource use. See also Other Issues Affecting IIS Performance later in this document.
Managed Code Tuning Parameters
· Make sure to precompile all scripts. This can be accomplished by calling one .NET script in each directory. Reset IIS after compilation is complete. Recompile after changes to Machine.config, Web.config or any .aspx script.
· If session state is not needed, make sure to turn it off in each page.
· When running multiple hosts containing ASP.NET scripts in isolated mode (one application pool per site) monitor the memory usage. Make sure the IIS server has enough RAM for the expected number of concurrently running application pools. Consider using multiple app-domains in place of multiple isolated processes.
" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif"> Other Issues Affecting IIS Performance
· Installing Non Cache-Aware Filters. The installation of a filter that is non-HTTP-cache-aware will cause IIS to disable caching altogether, resulting in a poor performance. Old ISAPI filters (written before IIS 6.0) can cause this behavior. Filters that can operate with the HTTP cache can be marked cache-aware in the metabase.
· CGI Requests. Use of CGI applications for serving requests is not recommended under IIS for performance reasons. Frequent creation (and deletion) of CGI processes involves significant overhead. Better alternatives include use of ISAPI application and ASP or ASP.NET scripts. Isolation is available for each of these options.
NTFS File System Setting
Under HKLM\System\CurrentControlSet\Control\FileSystem\ is NtfsDisableLastAccessUpdate (REG_DWORD) 1.
This system-global switch reduces disk I/O load and latencies by disabling the updating of the date and time stamp for the last file or directory access. This key needs to be added; it does not exist by default. Disabling the updates is effective when used with large data sets (or a large number of hosts) containing thousands of directories. It is recommended that you use IIS logging instead if you maintain this information for Web administration only.
Warning: Some applications such as incremental backup utilities rely on this update information and cease to function properly without it.
Tcpip.sys Performance Settings for IIS
See Performance Tuning for Networking earlier in this document.
Network Adapter Tuning and Binding for IIS
· Make sure all network adapter settings are optimal.
· Bind each network adapter to a CPU (the method to use depends on the number of network adapters, the number of CPUs and the number of ports per network adapter).
See also Performance Tuning for Networking earlier in this document.
