IIS 6.0: Designed for Speed and Fault Tolerance

In my May 6 commentary ( http://www.winnetmag.com/windowsserver2003/index.cfm?articleid=38980 ), I wrote about the impressive performance improvements in IIS 6.0 over previous versions and reported the results of independent performance tests. With IIS 6.0 now shipping and making its way to production environments, I want to cover IIS 6.0's architecture and look in more detail at its performance, scalability, and availability (i.e., fault tolerance) features.

Microsoft completely rewrote IIS 6.0 from the ground up. Undertaking a complete rewrite is unusual for Microsoft. But when the company completed its analysis, proofs of concepts, and prototypes in the design phase a few years ago, Microsoft determined that rewriting the software would be well worth the time and effort. That effort paid off. The architecture of IIS 6.0 consists of a combination of kernel-mode processes, user-mode processes, and Windows services. Four individual core components differentiate IIS 6.0 from its predecessors: - The IIS Admin Service--The IIS Admin Service is a Windows NT service that manages IIS's nonWeb server-related protocols (FTP, SMTP, Network News Transfer Protocol--NNTP--and the IIS metabase). - The Kernel Mode HTTP Listener--Named Http.sys, this HTTP stack is implemented as a kernel-mode device driver. Although Http.sys is part of the Windows Server 2003 OS, Microsoft leverages it as a core component of IIS 6.0. Http.sys services HTTP requests, manages TCP connections and IIS logging services, and implements Quality of Service (QoS) functionality and other services. - Worker Processes--The request processor typically functions by returning a static page, invoking an Internet Server API (ISAPI) extension or filter, or running a Common Gateway Interface (CGI) handler. Physically implemented as W3wp.exe, the worker processes also run application code, such as ASP.NET applications. - The Web Administration Service (WAS)--The WAS is responsible for configuration and process management in IIS. In its configuration role, WAS interacts with the metabase to obtain the configuration data that is either passed into Http.sys or used when managing a worker process. In its management role, WAS manages the worker processes, which includes starting the worker processes and maintaining information about worker processes that are running.

So, what does all this mean? In what Microsoft calls IIS 5.0 Isolation Mode, IIS 6.0 is architecturally and functionally compatible with IIS 5.0. But more interesting is worker process isolation mode, which is the default mode of operation. Worker process isolation mode takes advantage of the redesigned architecture of IIS 6.0. Worker process isolation mode leverages all the new IIS 6.0 core components and results in increased isolation, reliability, availability, and performance. The use of worker process isolation mode enables the application pooling, recycling, and health-detection features.

Depending on how you configure IIS 6.0, you can potentially have multiple instances of the worker processes running and serving different Web applications concurrently. IIS 6.0's design separates applications by process boundaries, resulting in maximum Web server reliability. In worker process isolation mode, application-specific code (e.g., ASP and ASP.NET applications) is loaded into only the worker process, which makes IIS highly reliable because WAS, the IIS Admin Service, and Http.sys remain up and running despite any service interruptions that might occur in a worker process.

Web sites running in worker processes also aren't affected by failures in other worker processes because the sites are isolated from each other by process boundaries. A programmer error can't take an entire IIS 6.0 Web server down as could happen in IIS 5.0 and earlier versions. Here's how the process works internally: When a Web site is created in IIS 6.0, it's registered with Http.sys to receive HTTP requests. Http.sys then works as a router and sends received Web requests to the user mode process in the Web site that's running the application. Http.sys also delivers responses to the client. Because Http.sys only routes requests and doesn't process them (other than retrieving a stored response from its internal cache), no developer-created application-specific code is ever loaded into kernel mode, so you don't have to worry that a possible coding error will affect the kernel and lead to a system failure or blue screen. IIS 6.0 is thereby fault tolerant.

IIS 6.0 really isn't the 6th version of IIS to ship from Microsoft. Rather, it's the first version of Microsoft's first enterprise Web server. IIS 6.0 has become an application server that provides incredible performance, scalability, and availability.