Worker Process Isolation Mode

   

---

IIS 6.0 introduces worker process isolation mode, which runs all application code in an isolated environment but without the performance penalty of the previous IIS versions. HTTP requests are routed to the correct application pool queue: user -mode worker processes serving an application pool pull the requests directly from HTTP.sys and eliminate the unnecessary process hops encountered when having to send a request to an out-of-process DLL host and back again.

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 application or Web site from disrupting other Web applications (or other Web sites) served from other worker processes on that server. 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 has been re-architected to support many more concurrent processes than ever before.

The IIS 6.0 worker process isolation mode approach is to allow administrators to put different Web applications or Web sites into application pools. For example, a departmental server might have Web-HR in one application pool and Web-Finance in another; an Internet service provider (ISP) might have CustomerX.com in one application pool and CustomerY.com in another.

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 , such as taking a site or an application on line or off line (independently of all other applications running on the system), changing a component the application uses, debugging the application, monitoring counters for the application, and throttling resources used by the application.

Application Pools

Application pools define a set of Web applications that share one or more worker processes. Each application pool is separated from other application pools by process boundaries. An application that is routed to one application pool is not affected by other application pools, and that application 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. Application pools are effectively namespace groups. In HTTP.sys, application pools are represented by a request queue that the user-mode worker processes serving an application pool can grab requests from.

Isolation Improvements

Specifically, worker process isolation mode improves upon its predecessors in the following areas:

• Robustness.

  This architecture prevents different Web applications or Web sites served by IIS 6.0 worker process isolation mode from harming one another or the server as a whole.

• No reboots.

  The user is never forced to reboot the server, or even shut down the entire WWW service. Common operations, such as upgrading content or components, debugging Web applications, and dealing with faulty Web applications, shouldn't affect service to other sites or applications on the server.

• Self-healing.

  IIS 6.0 supports auto-restart of failed applications and periodic restart of leaky/malfunctioning applications or applications with faulty code.

• Scalable.

  IIS 6.0 supports scaling to ISP scenarios, wherein hundreds to thousands of sites might be on a server. IIS 6.0 also supports Web gardens, in which each worker process in a set of equivalent worker processes on a server receives a share of the requests that are normally served by a single worker process. This supports better multiprocessor scalability.

• Strong application notion.

  IIS 6.0 supports the application as the unit of administration. This includes making the application the unit of robustness by enabling application isolation, and also enabling resource throttling and scaling based on the application.

The end result is a Web server that is more reliable and always available, even if applications cause their hosting worker processes to terminate. Worker process isolation mode takes the concept of application isolation, introduced in IIS 4.0, much further. Applications can be completely isolated from one another, such that one application error does not affect another application in a different process. IIS 6.0 worker process isolation mode also allows for better isolation while not incurring a performance penalty for isolation. Requests are pulled directly from the kernel instead of being pulled by a user-mode process from the kernel for the application; they then route accordingly to another user-mode process.

Improved Robustness

Worker process isolation mode contains the following features that improve its robustness without a performance hit:

• 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 in that 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 ”DLLHOST.EXE. When IIS 6.0 operates in worker process isolation mode, administrators can create multiple application pools, wherein each application pool can have a different configuration.

• Better support for load balancers.

  With the advent of application pools, IIS has a well-defined physical separation of applications ”so much so that it's quite feasible to run hundreds or thousands of sites or applications side by side on one Windows server. In this configuration, it's important that one problematic application not affect other, healthy, applications. It's also desirable to be able to automatically communicate with load balancers and switches to route away only the traffic for a problematic application while still allowing the server to accept requests for the other, healthy, applications. As an example, imagine a server processing requests for applications A and B. If application B fails so often that IIS decides to automatically shut it down (see the upcoming discussion of rapid-fail protection), the server should still be able to receive requests for application A. IIS 6.0 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.

  IIS 6.0 worker process isolation mode also allows multiple worker processes to 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 equivalent worker processes share the work. This configuration is known as a Web garden because it's similar 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 . This distribution is based on matching the queue of incoming requests for an application pool against a queue of requests for requests from each set of processes in the Web garden. A benefit of Web gardens is that if one worker process gets bogged down (script engine hangs ), other worker processes are available to accept and process requests.

• Health monitoring.

  The WWW service is capable of monitoring the health of worker processes by pinging the worker processes periodically to determine whether they are completely blocked. If a worker process is blocked, the WWW service terminates the worker process and creates another worker process for replacement. Furthermore, 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.

• 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 ”one in which the root namespace (/) is configured as an application. An application pool can be configured to serve anything: from one Web application to multiple applications to multiple sites. Assigning an application to an application pool is as easy as configuring which application pool an application should be routed to in 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 IIS 6.0 application manager (contained within the WWW service) is the component that does on-demand process starting and generally controls and monitors the life cycles of worker processes.

• Idle timeout.

  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.

• Rapid-fail protection.

  When a worker process fails, it drops the communication channel with the WWW service. The WWW service 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 so that if a particular application pool suffers multiple failures in a row, it can be automatically disabled. 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. An administrator can also explicitly put a namespace group in out-of-service mode: for example, if the application is being taken off line because of a serious application problem. The administrator does this by stopping the application pool with either IIS Manager or a script.

• Orphaning worker processes.

  Worker process isolation mode can be configured to orphan any worker process that it deems to be terminally ill . If a worker process fails to respond to a ping in a certain amount of time, the WWW service marks that worker process as terminally ill. Normally the WWW service terminates that worker process and starts 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 (such as 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 reboot or 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 Restarts

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

• A liveliness ping, which the process must respond to (See the earlier bullet regarding health monitoring.)

• Virtual memory usage

• Physical memory usage

• On demand

When a worker process restarts, the WWW service 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 approach 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.

IIS 5.0 Isolation Mode

IIS 6.0 introduces worker process isolation mode in an effort to bring greater reliability, isolation, availability, and performance to Web servers. While worker process isolation mode offers increased isolation, reliability, availability, and performance, some applications might not work in its environment because of compatibility issues, such as session states persisting in process or applications written as read raw data filters. Therefore, IIS 6.0 has the ability to switch to another process model, called IIS 5.0 isolation mode, to ensure compatibility.

IIS 5.0 isolation mode operates similarly to IIS 5.0. Essentially everything above the kernel mode, called user mode, operates in the same fashion as IIS 5.0. Because the same essential user mode processes exist as in IIS 5.0, IIS 5.0 isolation mode is the most compatible way for users to run IIS 6.0. The same methods of application isolation ”low, medium (pooled), and high ”exist, and Inetinfo.exe is still the master process through which each request must transverse.

Also, IIS 5.0 isolation mode receives the same benefits from HTTP.sys as does worker process isolation mode: kernel-mode request queuing and kernel-mode caching. IIS 6.0 redesigns the way a Web service talks to HTTP.sys.

Note

All other services contained within Inetinfo, such as FTP and SMTP, still work as they did in IIS 5.0, and they are still contained within Inetinfo. Only the WWW service has been changed to pull requests from HTTP.sys.

---

Top