IIS 6.0 Architecture

IIS 6.0 Architecture—A New RequestProcessing Architecture

Web site and application code is becoming increasingly complex. Dynamic Web sites and applications might contain imperfect code that leaks memory or causes errors such as access violations. Therefore, a Web server must be an active manager of the application run-time environment and automatically detect and respond to application errors. When an application error occurs, the server needs to be fault-tolerant, meaning it must actively recycle and restart a faulty application while continuing to queue requests for the application and not interrupting the end-user’s experience. IIS 6.0 features a new fault-tolerant request processing architecture that has been designed to provide this robust and actively managed runtime, and achieve dramatically increased reliability and scalability by combining a new process isolation model, called worker process isolation mode, with performance enhancements such as kernel mode queuing and caching.

The previous version of IIS, IIS 5.0, was designed to have one process, named Inetinfo.exe, function as the main Web server process. This process transferred requests to “out of process” applications hosted in DLLHost.exe processes. In comparison, IIS 6.0 has been redesigned into two new components, a kernel-mode HTTP protocol stack (HTTP.sys) and a user-mode administration and monitoring component. This architecture allows IIS 6.0 to separate the operations of the Web server from the processing of Web site and application code—without sacrificing performance. These two major components of the IIS 6.0 fault-tolerant architecture are:

·   HTTP.sys. A kernel-mode HTTP protocol stack that queues and parses incoming HTTP requests, and caches and returns application and site content. HTTP.sys does not load any application code, it simply parses and routes requests.

·   WWW Service Administration and Monitoring component. A user-mode configuration and process manager that manages server operations and monitors the execution of application code. Like HTTP.sys, this component doesn’t load or process any application code.

Before discussing these components, it is important to introduce two new IIS 6.0 concepts: application pools and worker processes.

Application pools are used to manage a set of Web sites and applications. Each application pool corresponds to one request queue within HTTP.sys and the one or more Windows processes that process these requests. IIS 6.0 can support up to 2,000 application pools per server, and there can be multiple application pools operating at the same time. For example, a departmental server might have HR in one application pool and finance in another application pool. An Internet Service Provider (ISP) might have the Web sites and applications of one customer in one application pool, and the Web sites of another customer in a different application pool. Application pools are separated from other application pools by Windows Server 2003 process boundaries. Therefore, an application in one application pool is not affected by applications in other application pools, and an application request cannot be routed to another application pool while being serviced by the current application pool. Applications can easily be assigned to another application pool while the server is running.

A worker process services requests for the Web sites and applications in an application pool. All Web application processing, including loading of ISAPI filters and extensions, as well as authentication and authorization, is done by a new WWW service DLL, which is loaded into one or more host worker processes. The worker process executable is named W3wp.exe.

HTTP.sys

In IIS 6.0, HTTP.sys listens for requests and queues them appropriately. Each request queue corresponds to one application pool. Because no application code runs in HTTP.sys, it cannot be affected by failures in user-mode code that normally affect the status of the Web service. If an application fails, HTTP.sys continues to accept and queue new requests on the appropriate queue until one of the following: the process has been restarted and begins to accept requests, there are no queues available, there is no space left on the queues, or the Web service itself has been shut down by the administrator. Because HTTP.sys is a kernel-mode component, its queuing operation is especially efficient, enabling the IIS 6.0 architecture to combine process isolation with high performance request processing.

Once the WWW service notices the failed application, it starts a new worker process if there are outstanding requests still waiting to be serviced for the worker process’s application pool. Thus, while there may be a temporary disruption in user-mode request processing, an end user does not experience the failure, because requests continue to be accepted and queued.

WWW Service Administration and Monitoring Component

The WWW Service Administration and Monitoring component makes up a core portion of the WWW service. Like HTTP.sys, no application code runs in the WWW Service Administration and Monitoring component. This component has two primary responsibilities: system configuration and worker process management.

Server Configuration

At initialization time, the configuration manager portion of WWW service uses the in-memory configuration metabase to initialize the HTTP.sys namespace routing table. Each entry in the routing table contains information that routes incoming URLs to the application pool that contains the application associated with the URL. These pre-registration steps inform HTTP.sys that there is an application pool that responds to requests in a particular part of the namespace, and that HTTP.sys can request that a worker process be started for the application pool when a request arrives. All pre-registrations are done before HTTP.sys begins to route requests to individual processes. As application pools and new applications are added, the Web service configures HTTP.sys to accept requests for the new URLs, sets up the new request queues for the new application pools, and indicates where the new URLs should be routed. Routing information can change dynamically without requiring a service restart.

Worker Process Management

In the worker process management role, the WWW Service Administration and Monitoring component is responsible for controlling the lifetime of the worker processes that process the requests. This includes determining when to start, recycle, or restart a worker process, if it is unable to process any more requests (becomes blocked). It is also responsible for monitoring the worker processes, and can detect when a worker process has terminated unexpectedly.

Worker Process Isolation Mode

IIS 6.0 introduces a new application isolation mode for managing the processing of Web sites and applications: worker process isolation mode. Worker process isolation mode runs all application code in an isolated environment without incurring a performance penalty for that isolation. Applications can be completely isolated from each other, where one application error does not affect another application in a different process, using application pools. Requests are pulled directly from the kernel instead of having a user-mode process pull them from the kernel for the application, and then route accordingly to another user-mode process. First, HTTP.sys routes Web site and application requests to the correct application pool queue. Then, the worker processes serving the application pool pull requests directly from the application queue in HTTP.sys. This model eliminates the unnecessary process hops encountered when sending a request to an out-of-process DLLHost.exe and back again (as was the case in IIS 4.0 and 5.0), and increases performance.

It is important to note that, in IIS 6.0, there is no longer any notion of in-process applications. All necessary HTTP application run-time services, such as ISAPI extension support, are equally available in any application pool. This design prevents a malfunctioning Web site or application from disrupting the operation of other Web applications or the server itself. With IIS 6.0 it is now possible to unload in-process components without having to take down the entire Web service. The host worker process can be taken down temporarily without affecting other worker processes serving content. There is also a benefit from being able to leverage other operating system services available at the process level (for example CPU throttling), per application pool. Additionally, Windows Server 2003 has been re-architected to support many more concurrent processes than ever before.

Worker process isolation mode prevents one application or site from stopping another. In addition, separating applications or sites into separate worker processes simplifies a number of management tasks, for example: taking a site/application online or offline (independent of all other site/applications running on the system), changing a component the application uses, debugging an application, monitoring counters for an application, and throttling resources used by an application.

Features of IIS 6.0 worker process isolation mode include:

·    Kernel-mode caching. Windows Server 2003 introduces a new kernel-mode HTTP driver called HTTP.sys, which is specifically tuned to increase Web server performance and scalability. Kernel-mode caching is available when using IIS 6.0, both in worker process isolation mode and in IIS 5.0 isolation mode (see below). As a single point of contact for all incoming (server-side) HTTP requests, HTTP.sys provides high-performance connectivity for HTTP server applications and provides overall connection management, bandwidth throttling, and Web server logging. IIS 6.0 has been built on top of HTTP.sys and has been specifically tuned to increase Web server throughput. In addition, under specific circumstances, HTTP.sysdirectly processes requests in the kernel. Both static and dynamic content from Web sites and applications can be cached in the HTTP.sys cache for high-performance responses.

·    Clean separation between user code and the server. All user code is handled by worker processes, which are completely isolated from the core Web server. This improves upon IIS 5.0, because an ISAPI can be, and often is, hosted in-process to the core Web server. If an ISAPI loaded in a worker process fails or causes an access violation, the only thing taken down is the worker process that hosts the ISAPI. Meanwhile, the WWW service creates a new worker process to replace the failed worker process. The other worker processes are unaffected.

·    Multiple application pools. With IIS 5.0, applications can be pooled together out-of-process, but only in one application pool, which is hosted by DLLHost.exe. When IIS 6.0 operates in worker process isolation mode, administrators can create up to 2,000 application pools, where each application pool can be configured separately.

·    Better support for load balancers. With the advent of application pools, IIS 6.0 has a well-defined physical separation of applications; it is quite feasible to run hundreds or even thousands of sites/applications side by side on one IIS 6.0 server. In worker process isolation mode, it is important that errors in one application do not affect other applications. IIS 6.0 can also automatically communicate with load balancers/switches to route away only the traffic for a problematic application, while still allowing the server to accept requests for the other, healthy applications. For example, imagine a server processing requests for applications A and B. If application B fails so often that IIS 6.0 decides to automatically shut it down (see section on rapid fail protection below), the server should still be able to receive requests for application A. IIS 6.0 also has a built-in extensibility model that can fire events and commands when the WWW service detects a specific application’s failure. This configuration ability allows load balancers and switches to be configured to automatically stop routing traffic to problematic applications while still routing traffic to healthy applications.

·    Web gardens. Multiple worker processes can be configured to service requests for a given application pool. By default, each application pool has only one worker process. However, an application pool can be configured to have a set of Nequivalent worker processes that share the workload. This configuration is known as a Web garden because it is similar in nature to a Web farm, the difference being that a Web garden exists within a single server. Requests are distributed by HTTP.sys among the set of worker processes in the group. The distribution of requests is based on a round-robin scheme, where new connections with requests for the application pool are assigned to specific worker processes in that application pool. A benefit to Web gardens is that if one worker process slows down, such as when the script engine becomes unresponsive, there are other worker processes available to accept and process requests.

·    Health monitoring. The WWW Service Administration and Monitoring Component monitors the health of applications by pinging worker processes periodically to determine if they are completely blocked. If a worker process is blocked, the WWW service terminates the worker process and creates another worker process in its place. The WWW service maintains a communication channel to each worker process and can easily tell when a worker process fails by detecting a drop in the communication channel.

·    Processor affinity. Worker processes can have an affinity to specific CPUs to take advantage of more frequent CPU cache (L1 or L2) hits. Processor affinity, when implemented, forces IIS 6.0 worker processes to run on specific microprocessors or CPUs and applies to all worker processes serving the Web sites and applications of an application pool. Processor affinity can also be used with Web gardens that run on multiprocessor computers where clusters of CPUs have been dedicated to specific application pools.

·    Allocating sites and applications to application pools. In IIS 6.0, as in IIS 5.0, applications are defined as those namespaces that are labeled in the metabase with the AppIsolated property. Sites, by default, are considered to be a simple application—where the root namespace “/” is configured as an application. An application pool can be configured to serve anything—from one Web application to multiple applications, up to multiple sites. You can assign an application to an application pool using IIS Manager or directly editing the metabase.

·    Demand start. Application pools get benefits. For example, on-demand starting of the processes that service the namespace group, when the first request for a URL in that part of the namespace arrives at the server. The WWW Service Administration and Monitoring Component does on-demand process starting, and generally controls and monitors the life cycle of worker processes.

·    Idle time-out. An application pool can be configured to have its worker processes request a shutdown if they are idle for a configurable amount of time. This is done to free up unused resources. Additional worker processes are started when demand exists for that application pool. (For more information, see the section on Demand Start above.)

·    Rapid-fail protection. When a worker process fails, it drops the communication channel with the WWW Service Administration and Monitoring component. The WWW Service Administration and Monitoring component detects this failure and takes action, which typically includes logging the event and restarting the worker process. In addition, IIS 6.0 can be configured to automatically disable the worker process if a particular application pool suffers a configurable number of failures in a row in a configured time period. This is known as rapid-fail protection. Rapid-fail protection places the application pool in "out-of-service" mode and HTTP.sys immediately returns a 503–Service Unavailable, out-of-service message to any requests to that portion of the namespace—including requests already queued for that application pool.

·    Orphaning worker processes. Worker process isolation mode can be configured to “orphan” any worker process that it deems “terminally ill.” For example, if a worker process fails to respond to a ping message in the configured time period, normally the WWW service would terminate that worker process and start a replacement. If “orphaning” is turned on, the WWW service leaves the “terminally ill” worker process running and starts a new process in its place. Also, the WWW service can be configured to run a command on the worker process (like attaching a debugger) when it “orphans” a worker process.

·    Recycling worker processes. Today, many businesses and organizations have problems with Web applications that leak memory, suffer from poor coding, or have indeterminate problems. This forces administrators to restart their Web servers periodically. In previous versions of IIS, it was not possible to restart a Web site without an interruption of the entire Web server. Worker process isolation mode can be configured to periodically restart worker processes in an application pool to manage faulty applications. Worker processes can be scheduled to restart based on the following criteria: elapsed time, number of requests served, scheduled times during a 24-hour period, virtual memory usage, physical memory usage, and on demand. When a worker process wants to restart, it notifies the WWW service which then tells the existing worker process to shut down and gives a configurable time limit for the worker process to drain its remaining requests. Simultaneously, the WWW service creates a replacement worker process for the same namespace group, and the new worker process is started before the old worker process stops. This process prevents service interruptions. The old worker process remains in communication with HTTP.sys to complete its outstanding requests, and then shuts down normally, or is forcefully terminated if it does not shut down after a configurable time limit.