|
Performance Tuning Guidelines for Windows Server 2003
|
| bet | 5/61 | | Sana | 21.03.2017 | | Hajmi | 430,5 Kb. | | #1046 |
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.
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.
|
| |
