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 network adapter.
The file system becomes a bottleneck because of an inefficient disk subsystem or storage adapter.
Operating System Practices
If possible, perform a clean installation of the operating system software. Upgrading the software 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 you must keep it, 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 page file, operating system, web data, ASP template cache, and the Internet Information Services (IIS) log on separate physical disks if possible.
To reduce contention for system resources, install SQL Server 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 8.0
Internet Information Services (IIS) 8.0 is the version that ships as part of Windows Server 2012 . It uses a process model similar to that of IIS 6.0. A kernel-mode web driver (http.sys) receives and routes HTTP requests, and it can 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 8.0 process relies on the kernel-mode web driver, http.sys. Http.sys is responsible for connection management and request handling. The request can be served from the http.sys cache or passed to a worker process for further handling (see Figure 11). 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 11 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-mode cache. The static file handler in IIS 8.0 automatically caches frequently requested files in http.sys.
Figure 11. Request handling in IIS 8.0
Because a web server has kernel-mode and user-mode components, both components must be tuned for optimal performance. Therefore, tuning IIS 8.0 for a specific workload includes configuring the following:
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 the kernel mode, which significantly lowers the CPU cost of handling the request. However, the kernel-mode cache of IIS 8.0 is based on physical memory, 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 or not the entry is being used. 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 caching. For most workloads, the cache should remain enabled. Consider disabling the cache if you expect a very low response and fragment caching.
UriMaxCacheMegabyteCount. Default value: 0.
A nonzero value specifies the maximum memory that is available to the kernel-mode cache. The default value, 0, enables the system to automatically adjust how much memory is available to the cache.
Note Specifying the size sets only the maximum, and the system might not let the cache grow to the specified size.
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 too low causes more frequent scavenger scans, and it can result in too many flushes and cache churn.
Request and Connection Management Settings
In Windows Server 2012, http.sys manages connections automatically. The following registry keys that were used in earlier releases are considered deprecated and are not necessary in Windows Server 2012: