Tuning IIS 6.0
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.
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.
|
