Selecting the Proper Hardware for Performance
It is important to select the proper hardware to satisfy the expected Web load, considering average load, peak load, capacity, growth plans, and response times. Hardware bottlenecks limit the effectiveness of software tuning. “Choosing and Tuning Server Hardware” earlier in this guide provides recommendations for hardware to avoid the following performance constraints:
Slow CPUs offer limited processing power for ASP, ASP.NET, and SSL scenarios.
A small L2 processor cache might adversely affect performance.
A limited amount of memory affects the number of sites that can be hosted, how many dynamic content scripts (such as ASP.NET) can be stored, and the number of application pools or worker processes.
Networking becomes a bottleneck because of an inefficient networking adapter.
The file system becomes a bottleneck because of an inefficient disk subsystem or storage adapter.
Operating System Practices
If possible, do a clean installation of the operating system software. Upgrading can leave outdated, unwanted, or suboptimal registry settings and previously installed services and applications that consume resources if they are started automatically. If another operating system is installed and must be kept, you should install the new operating system on a different partition. Otherwise, the new installation overwrites the settings under Program Files\Common Files.
To reduce disk access interference, place the system pagefile, operating system, Web data, ASP template cache, and Internet Information Services (IIS) log on separate physical disks if possible.
To reduce contention for system resources, install SQL and IIS on different servers if possible.
Avoid installing nonessential services and applications. In some cases, it might be worthwhile to disable services that are not required on a system.
Tuning IIS 7.5
Internet Information Services (IIS) 7.5 is the version that ships as part of Windows Server 2008 R2. It uses a process model similar to that of IIS 6.0. 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 for application pools).
The IIS 7.5 process relies on the kernel-mode Web driver, Http.sys. Http.sys is responsible for connection management and request handling. The request can be either served from the Http.sys cache or handed to a worker process for further handling (see Figure 5). Multiple worker processes can be configured, which provides isolation at a reduced 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 potentially up to a worker process. Some Web application platforms, such as ASP.NET, provide mechanisms to enable any dynamic content to be cached in the kernel cache. The static file handler in IIS 7.5 automatically caches frequently requested files in Http.sys.
Figure 5. Request Handling in IIS 7.5
Because a Web server has a kernel-mode and a user-mode component, both components must be tuned for optimal performance. Therefore, tuning IIS 7.5 for a specific workload includes configuring the following:
Http.sys (the kernel-mode driver) and the associated kernel-mode cache.
Worker processes and user-mode IIS, including application pool configuration.
Certain tuning parameters that affect performance.
The following sections discuss how to configure the kernel-mode and user-mode aspects of IIS 7.5.
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 the HTTP service is already running, you must restart it for the changes to take effect.
Cache Management Settings
One benefit that Http.sys provides is a kernel-mode cache. If the response is in the kernel-mode cache, you can 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 7.5 is a physical memory–based cache and the cost of an entry is the memory that it occupies.
An entry in the cache is helpful only when it is used. However, the entry always consumes physical memory, whether the entry is being used or not. You must evaluate the usefulness of an item in the cache (the savings from being able to serve it from the cache) and its cost (the physical memory occupied) over the lifetime of the entry by considering the available resources (CPU and physical memory) and the workload requirements. Http.sys tries to keep only useful, actively accessed items in the cache, but you can increase the performance of the Web server by tuning the Http.sys cache for particular workloads.
The following are some useful settings for the Http.sys kernel-mode cache:
UriEnableCache. Default value 1.
A nonzero 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 usage.
UriMaxCacheMegabyteCount. Default value 0.
A nonzero value specifies the maximum memory that is available to the kernel cache. The default value, 0, enables the system to automatically adjust how much memory is available to the cache. Note that specifying the size sets only the maximum and the system might not let the cache grow to the specified size.
UriMaxUriBytes. Default value 262144 bytes (256 KB).
This is the maximum size of an entry in the kernel-mode cache. Responses or fragments larger than this are not cached. If you have enough memory, consider increasing the limit. If memory is limited and large entries are crowding out smaller ones, it might be helpful to lower the limit.
UriScavengerPeriod. Default value 120 seconds.
The Http.sys cache is periodically scanned by a scavenger, and entries that are 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 might increase because older, less frequently accessed entries can remain in the cache. Setting the period to too low a value causes more frequent scavenger scans and might result in too many flushes and cache churn.
Request and Connection Management Settings
Http.sys also manages incoming HTTP/HTTPS connections and is the first layer to handle requests on those 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 reserve some in look-aside lists. Keeping such reserves helps 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, can result in load fluctuations and spikes.
The reserves help reduce CPU usage and latency, and they increase Web server capacity but increase memory usage. When you tune the request and connection management behavior of Http.sys, you should remember the resources that are available to the server, your performance goals, and the characteristics of the workload. Use the following request and connection management setting:
This value controls the number of concurrent connections that Http.sys allows. Each connection consumes nonpaged pool, a precious and limited resource. The default is determined very conservatively to limit how much nonpaged pool is used for connections. On a dedicated Web server that has ample memory, you should set the value higher if you expect a significant concurrent connection load. A high value can result in increased nonpaged pool usage, so make sure to use a value that is appropriate for the system.
The following registry keys were deprecated for Windows Server 2008 R2:
IdleConnectionsHighMark, IdleConnectionsLowMark, and IdleListTrimmerPeriod
These values control the handling of connection structures that are currently not being used: 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 that are related to buffer management and how many are kept in reserve to handle load fluctuations.
User-Mode Settings
The settings in this section affect the IIS 7.5 worker process behavior. Most of these settings can be found in the %SystemRoot%\system32\inetsrv\config
\applicationHost.config XML configuration file. Use either Appcmd.exe or the IIS 7.5 management console to change them. Most settings are automatically detected and do not require a restart of the IIS 7.5 worker processes or Web Application Server.
User-Mode Cache Behavior Settings
This section describes the settings that affect caching behavior in IIS 7.5. The user-mode cache is implemented as a module that listens to the global caching events that the integrated pipeline raises. To completely disable the user-mode cache, remove the FileCacheModule (Cachfile.dll) module from the list of installed modules in the system.webServer/globalModules configuration section in applicationHost.config.
system.webServer/caching
Attribute
|
Description
|
Default
|
enabled
|
Disables the user-mode IIS cache when set to false. When the cache hit rate is very small, you can disable the cache completely to avoid the overhead that is associated with the cache code path. Disabling the user-mode cache does not disable the kernel-mode cache.
|
True
|
enableKernelCache
|
Disables the kernel-mode cache when set to false.
|
True
|
maxCacheSize
|
Limits the IIS user-mode cache size to the specified size in megabytes. IIS adjusts the default depending on available memory. Choose the value carefully based on the size of the hot set (the set of frequently accessed files) versus the amount of RAM or the IIS process address space, which is limited to 2 GB on 32-bit systems.
|
0
|
maxResponseSize
|
Lets files up to the specified size be cached. 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. The default value is 256 KB.
|
262144
| Compression Behavior Settings
In Windows Server 2008 R2, IIS 7.5 compresses static content by default. Also, compression of dynamic content is enabled by default when the DynamicCompressionModule is installed. Compression reduces bandwidth usage but increases CPU usage. Compressed content is cached in the kernel-mode cache if possible. IIS 7.5 lets compression be controlled independently for static and dynamic content. Static content typically refers to content that does not change, such as GIF or HTM files. Dynamic content is typically generated by scripts or code on the server, that is, ASP.NET pages. You can customize the classification of any particular extension as static or dynamic.
To completely disable compression, remove StaticCompressionModule and DynamicCompressionModule from the list of modules in the system.webServer/globalModules section in applicationHost.config.
system.webServer/httpCompression
Attribute
|
Description
|
Default
|
staticCompression-EnableCpuUsage,
staticCompression-DisableCpuUsage,
dynamicCompression-EnableCpuUsage,
dynamicCompression-DisableCpuUsage
|
Enables or disables compression if the current percentage CPU usage goes above or below specified limits.
IIS 7.5 automatically disables compression if steady-state CPU increases above the disable threshold. Compression is re-enabled if CPU drops below the enable threshold.
|
50, 100, 50, and 90 respectively
|
directory
|
Specifies the directory in which compressed versions of static files are temporarily stored and cached. Consider moving this directory off the system drive if it is accessed frequently.
The default value is %SystemDrive%\inetpub\temp
\IIS Temporary Compressed Files.
|
See Description column
|
doDiskSpaceLimiting
|
Specifies whether a limit exists for how much disk space all compressed files, which are stored in the compression directory that is specified by directory, can occupy.
|
True
|
maxDiskSpaceUsage
|
Specifies the number of bytes of disk space that compressed files can occupy in the compression directory.
This setting might need to be increased if the total size of all compressed content is too large.
|
100 MB
|
system.webServer/urlCompression
Attribute
|
Description
|
Default
|
doStaticCompression
|
Specifies whether static content is compressed.
|
True
|
doDynamicCompression
|
Specifies whether dynamic content is compressed.
|
True (changed in Windows Server 2008 R2)
|
Note: For IIS 7.5 servers that have low average CPU usage, consider enabling compression for dynamic content, especially if responses are large. This should first be done in a test environment to assess the effect on the CPU usage from the baseline.
Tuning the Default Document List
The default document module handles HTTP requests for the root of a directory and translates them into requests for a specific file, such as Default.htm or Index.htm. On average, around 25 percent of all requests on the Internet go through the default document path. This varies significantly for individual sites. When an HTTP request does not specify a file name, the default document module linearly walks the list of allowed default documents, searching for each one in the file system. This can adversely affect performance, especially if reaching the content requires making a network round trip or touching a disk.
You can avoid the overhead by selectively disabling default documents and by reducing or ordering the list of documents. For Web sites that use a default document, you should reduce the list to only the default document types that are used. Additionally, order the list so that it begins with the most frequently accessed default document file name. Finally, you can selectively set the default document behavior on particular URLs by using custom configuration inside a location tag in applicationHost.config or by inserting a Web.config file directly in the content directory. This allows a hybrid approach, which will enable default documents only where they are necessary and will set the list to the correct file name for each URL.
To disable default documents completely, remove DefaultDocumentModule from the list of modules in the system.webServer/globalModules section in applicationHost.config.
system.webServer/defaultDocument
Attribute
|
Description
|
Default
|
enabled
|
Specifies that default documents are enabled.
|
True
|
element
|
Specifies the file names that are configured as default documents.
The default list is Default.htm, Default.asp, Index.htm, Index.html, Iisstart.htm, and Default.aspx.
|
See Description column
| Central Binary Logging
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.
You can enable central binary logging by setting the centralLogFileMode attribute to CentralBinary and setting the enabled attribute to True. Consider moving the location of the central log file off the system partition and onto a dedicated logging partition to avoid contention between system activities and logging activities.
system.applicationHost/log
Attribute
|
Description
|
Default
|
centralLogFileMode
|
Specifies the logging mode for a server. Change this value to CentralBinary to enable central binary logging.
|
Site
|
system.applicationHost/log/centralBinaryLogFile
Attribute
|
Description
|
Default
|
enabled
|
Specifies whether central binary logging is enabled.
|
False
|
directory
|
Specifies the directory where log entries are written.
The default directory is: %SystemDrive%\inetpub\logs\LogFiles
|
See Des-cription column
| Application and Site Tunings
The following settings relate to application pool and site tunings.
system.applicationHost/applicationPools/applicationPoolDefaults
Attribute
|
Description
|
Default
|
queueLength
|
Indicates to the Universal Listener how many requests are queued for an application pool before future requests are rejected. When the value for this property is exceeded, IIS rejects subsequent requests with a 503 error.
Consider increasing this for applications that communicate with high-latency back-end data stores if 503 errors are observed.
|
1000
|
enable32BitAppOnWin64
|
When True, enables a 32-bit application to run on a computer that has a 64-bit processor.
Consider enabling 32-bit mode if memory consumption is a concern. Because pointer sizes and instruction sizes are smaller, 32-bit applications use less memory than 64-bit applications. The drawback to running 32-bit applications on a 64-bit machine is that user-mode address space is limited to 4 GB.
|
False
|
system.applicationHost/sites/VirtualDirectoryDefault
Attribute
|
Description
|
Default
|
allowSubDirConfig
|
Specifies whether IIS looks for Web.config files in content directories lower than the current level (True) or does not look for Web.config files in content directories lower than the current level (False).
When configuration is queried in the IIS 7.5 pipeline, it is not known whether a URL (/.htm) is a reference to a directory or a file name. By default, IIS 7.5 must assume that /.htm is a reference to a directory and search for configuration in a /.htm/web.config file. This results in an additional file system operation that can be costly.
By imposing a simple limitation, which allows configuration only in virtual directories, IIS 7.5 can then know that unless /.htm is a virtual directory it should not look for a configuration file. Skipping the additional file operations can significantly improve performance to Web sites that have a very large set of randomly accessed static content.
|
True
| Managing IIS 7.5 Modules
IIS 7.5 has been refactored into multiple, user-pluggable modules to support a more modular structure. This refactorization has a small cost. For each module present, the integrated pipeline must call into the module for every event that is relevant to the module. This happens regardless of whether the module must do any work. You can conserve CPU cycles and memory by removing all modules that are not relevant to a particular Web site.
A Web server that is tuned only for simple static files might include only the following five modules: UriCacheModule, HttpCacheModule, StaticFileModule, AnonymousAuthenticationModule, and HttpLoggingModule.
To remove modules from applicationHost.config, remove all references to the module from the system.webServer/handlers and system.webServer/modules sections in addition to the module declaration in system.webServer/globalModules.
Classic ASP Settings
The following settings apply only to classic ASP pages and do not affect ASP.NET settings. For performance recommendations on ASP.NET, see the article about high-performance Web applications in "Resources" later in this guide.
system.webServer/asp/cache
Attribute
|
Description
|
Default
|
diskTemplateCacheDirectory
|
This attribute contains the name of the directory that ASP uses to store compiled ASP templates to disk after overflow of the in-memory cache.
Recommendation: If possible, set to a platter not in heavy use, for example, not shared with the operating system, pagefile, IIS log, or other frequently accessed content.
The default directory is: %SystemDrive%\inetpub\temp
\ASP Compiled Templates
|
See Description column
|
maxDiskTemplateCacheFiles
|
This attribute specifies the maximum number of compiled ASP templates that can be stored.
Recommendation: Set to the maximum value of 0x7FFFFFFF.
|
2000
|
scriptFileCacheSize
|
This attribute specifies the number of precompiled script files to cache.
Recommendation: Set to as many ASP templates as memory limits allow.
|
500
|
scriptEngineCacheMax
|
This attribute specifies the maximum number of scripting engines that ASP pages will keep cached in memory.
Recommendation: Set to as many script engines as memory limits allow.
|
250
|
system.webServer/asp/limits
Attribute
|
Description
|
Default
|
processorThreadMax
|
Specifies the maximum number of worker threads per processor that ASP can create. Increase if the current setting is insufficient to handle the load, possibly causing errors when it is serving some requests or under-usage of CPU resources.
|
25
|
system.webServer/asp/comPlus
Attribute
|
Description
|
Default
|
executeInMta
|
Set to True if errors or failures are detected while it is serving some ASP content. This can occur, for example, when hosting multiple isolated sites in which 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.
|
False
| ASP.NET Concurrency Setting
By default, ASP.NET limits request concurrency to reduce steady-state memory consumption on the server. High concurrency applications might need to adjust some settings to improve overall performance. These settings are stored under the following registry entry:
HKEY_LOCAL_MACHINE\Software\Microsoft\ASP.NET\2.0.50727.0\Parameters
The following setting is useful for fully using resources on a system:
MaxConcurrentRequestPerCpu. Default value 12.
This setting limits the maximum number of concurrently executing ASP.NET requests on a system. The default value is conservative to reduce memory consumption of ASP.NET applications. Consider increasing this limit on systems that run applications that perform long, synchronous I/O operations. Otherwise, users can experience high latency because of queuing or request failures from exceeding queue limits under high load with the default setting.
Worker Process and Recycling Options
The options for recycling IIS worker processes under the IIS Administrator user interface provide practical solutions to acute situations or events without requiring intervention, a service reset, or even a computer reset. Such situations and events include memory leaks, increasing memory load, or unresponsive or idle worker processes. Under ordinary conditions, recycling options might not be needed and can be turned off or the system can be configured to recycle very infrequently.
You can enable process recycling for a particular application by adding attributes to the recycling/periodicRestart element. The recycle event can be triggered by several events including memory usage, a fixed number of requests, and a fixed time period. When a worker process is recycled, the queued and executing requests are drained and a new process is simultaneously started to service new requests. The periodicRestart element is per-application, meaning that each attribute in the table below will be partitioned on a per-application basis.
system.applicationHost/applicationPools/ApplicationPoolDefaults/recycling/periodicRestart
Attribute
|
Description
|
Default
|
memory
|
Enable process recycling if virtual memory consumption exceeds the specified limit in kilobytes. This is a useful setting for 32-bit machines that have a small, 2-GB address space to avoid failed requests because of out-of-memory errors.
|
0
|
privateMemory
|
Enable process recycling if private memory allocations exceed a specified limit in kilobytes.
|
0
|
requests
|
Enable process recycling after a certain number of requests.
|
0
|
time
|
Enable process recycling after a specified time period. (The default is 29 hours.)
|
29:00:00
| Secure Sockets Layer Tuning Parameters
The use of secure sockets layer (SSL) imposes additional CPU cost. The most expensive component of SSL is the session establishment cost (involving a full handshake), and 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 might need to be encrypted. However, mixing plain HTTP and HTTPS might 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 the Internet Server API (ISAPI) applications. If writing a private ISAPI extension, make sure that you code it efficiently for performance and resource use. See also “Other Issues that Affect IIS Performance” later in this guide.
Managed Code Tuning Guidelines
The new integrated pipeline model in IIS 7.5 enables a high degree of flexibility and extensibility. Custom modules that are implemented in native or managed code can be inserted into the pipeline or can replace existing modules. Although this extensibility model offers convenience and simplicity, you should be careful before you insert new managed modules that hook into global events. Adding a global managed module means that all requests, including static file requests, must touch managed code. Custom modules are susceptible to events such as garbage collection in addition to adding significant CPU cost because of marshaling data between native and managed code. If possible, you should implement global modules in native (C/C++) code.
When you first deploy an ASP.NET Web site, make sure that you precompile all scripts. You can do this 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 that you turn it off for each page.
When you run multiple hosts that contain ASP.NET scripts in isolated mode (one application pool per site), monitor the memory usage. Make sure that the server that runs has enough RAM for the expected number of concurrently running application pools. Consider using multiple application domains instead of multiple isolated processes.
For performance recommendations on ASP.NET, see the article about high-performance web applications in "Resources" later in this guide.
|
