Optimizing and Performance Tuning IIS 6.0
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Microsoft's Internet Information Services (IIS) has come a very long way since its beginning in 1996. With many businesses now using some version of IIS, it has been important for Microsoft to keep rolling out new versions of this web server to match increasing demands—both in terms of stability and performance. IIS 6.0, which is the latest and greatest version of IIS, rolls out with Windows Server 2003. How does it compare with earlier versions?
What's New In IIS 6.0?
This article takes a closer look at IIS 6.0, and discusses how to optimize, monitor, and tweak performance for both websites and applications. A good place to start is to learn about any new enhancements that IIS 6.0 has over IIS 5.0 in terms of stability and performance. The enhancements are discussed in detail in the following sections.
Improved Worker Process Management
In earlier versions of IIS, it was not possible to assign a single website or group of websites (application pool) to a single processor. In IIS 5.0, each website ran in its own separate memory space in the memory space for the web (www) service itself. If an error or malicious attack occurred on a website served by IIS 5.0, it was likely to crash the entire IIS www service, thus bringing the whole web server down.
With IIS 6.0, all websites run in their own separate worker processes or memory threads that are not only independent of each other, but also separate from the IIS www service process. This change not only makes IIS 6.0 more stable than any previous version without a performance penalty, but it also allows a single website or group of websites to be assigned to a single processor, and improves performance by taking advantage of that processor's frequent caching.
In IIS 5.0, each worker process was not monitored to see whether the process was responding. In IIS 6.0, each worker process is now monitored (or pinged) to make sure that it is responding, thus improving reliability.
Multiple Application Pools and Web Gardens
An application pool is a collection of one or more websites or applications assigned to run together in the same isolated memory space. In IIS 5.0, only one application pool was supported. If you wanted to improve performance and stability apart from the www service, you ran all your sites and applications in one isolated out-of-process application pool. This way, if one website or application failed, the www service wasn't affected. This is good, but there is still the likely possibility that if one site or application in the pool fails, the others in the pool will be disrupted.
IIS 6.0 resolves this issue by supporting multiple application pools that can support slightly different configurations and that are independent of each other. For example, if you had a site or application that fails periodically, you could isolate this site to be in its own application pool while the others are in their own pool or pools, effectively eliminating the possibility that the problematic site would disrupt any of the other sites. You can also configure application pools to have worker processes shut down if they are inactive for a certain amount of time, thus freeing up unused resources for other processes.
To further improve performance and stability over its predecessors, IIS 6.0 allows multiple worker processes to handle client connection requests routed to an application pool by distributing the requests across these multiple processes, without relying on just one process for the job. Much like a cluster, if one process becomes unresponsive, the others are there to continue handling the requests. An application pool configured to use multiple worker processes in this manner is referred to as a web garden.
New Request Processing
IIS 5.0 used to handle http requests with the web service process. IIS 6.0 relieves the web service process of this duty and has a new device driver (http.sys) to handle this task separately. Because http.sys takes over caching, connection management, bandwidth throttling, and logging from the www service process for a user request, web server performance is considerably enhanced. http.sys also improves the way these tasks are handled.
http.sys is a kernel mode device driver, so listening is done at the kernel level—separate from the user mode level. Static data can be cached faster at the kernel level than it can be at the user mode level (as it was in IIS 5.0). Connections from application pages (that is, asp.net pages) to databases are optimized because the kernel is faster at resolving these connections than was the www service. After the file caching and connections are handled for a request, http.sys determines whether sufficient bandwidth is available for the website or application to which the request was made. When bandwidth throttling is enabled for a site, a limit specified in the amount of kb/sec is defined. If the next request should exceed this limit, an error is displayed to the user that no more bandwidth is available. The overall benefits that IIS 6.0 gets by having http.sys parse http requests are an increase in the number of websites, active concurrent worker processes, and simultaneous requests that the web server can handle.