Evaluating the Benefits of Worker Process Isolation Mode

Applies To: Windows Server 2003, Windows Server 2003 with SP1

Worker process isolation mode provides higher levels of security and availability for Web sites and applications than IIS 5.0 isolation mode. Therefore, it is recommended that you configure IIS 6.0 to run in worker process isolation mode.

Worker process isolation mode provides the following improvements to IIS 6.0.

IIS 6.0 includes a variety of security features and technologies that help ensure the integrity of your Web site content, and of the data that is transmitted through your sites. The following security enhancement is only available when IIS 6.0 is running in worker process isolation mode.

In IIS 5.0 isolation mode, the default process identity is LocalSystem, which enables access to, and the ability to alter, nearly all of the resources on the Web server. The potential of attacks is reduced in worker process isolation mode because Web sites and applications run under the NetworkService identity. The NetworkService identity is granted less privileges, which helps prevent an attack from compromising the Web server, which is possible with the LocalSystem identity.

Future growth in the utilization of your Web sites and applications requires increased performance and scalability of Web servers. By increasing the speed at which HTTP requests can be processed and by allowing more applications and sites to run on one Web server, the number of Web servers that you need to host a site is reduced. The following are a few of the performance improvements included in worker process isolation mode.

You can configure all of the worker processes in an application pool to have affinity with specific processors in a multiprocessor or server. Processor affinity allows the worker processes to take advantage of more frequent processor caching (Level 1 or Level 2).

You can configure application pools to have worker processes request a shutdown if they are idle for a certain amount of time. This can free unused resources for other active worker processes. New worker processes are then started only when they are needed.

You can configure an application pool to have more than one worker process servicing client connections, also known as a Web garden. Because there are multiple worker processes, the incoming client connections are distributed across the worker processes and throughput is not constrained by a single worker process.

You can isolate applications without incurring a performance penalty.

Because worker process boundaries isolate the applications in an application pool from the applications in other application pools, if an application fails, it does not affect the availability of other applications running on the server. Deploying applications in application pools is a primary advantage of running IIS 6.0 in worker process isolation mode.

Many of the common operation tasks do not force the restart of the server or the Web service restart. These tasks, such as upgrading site content or components, debugging Web applications, or dealing with faulty Web applications, can be performed without affecting service to other sites or applications on the server.

In IIS 5.0 isolation mode, each Web site or application has only one worker process. However, in worker process isolation mode, you can create a Web garden by configuring a number of worker processes to share the processing. The benefit of a Web garden is that if one worker process stops responding, other worker processes are available to accept and process requests.

In worker process isolation mode, IIS can determine that a worker process is failing and start a new worker process to replace the failing worker process. Because a new worker process is created before the old worker process terminates, users requesting the Web site or application experience no interruption of service. After IIS creates the new worker process, the failed worker process can be separated, or orphaned, from the application pool. The advantage of orphaning a worker process rather than terminating it is that debugging can be performed on the orphaned worker process.

In worker process isolation mode, you can configure an application pool to monitor not only the health of the entire application pool, but also individual worker processes servicing the application pool. Monitoring the health of a worker process allows IIS to detect that a worker process is unable to serve requests and to take corrective action, such as recycling the failed worker process.

In addition, worker process isolation supports other responses when a failed worker process or application pool is detected. For example, IIS can attach a debugger to an orphaned worker process or notify an administrator that an application pool has failed due to rapid-fail protection.

In some cases, availability can be affected by Web sites and applications that fail very quickly, are automatically restarted, and then fail quickly again. The endless cycle of failure and restarting can consume system resources, causing other Web sites and applications to experience denial of services because of system resource shortages.

Worker process isolation mode includes rapid fail protection that stops an application pool when too many of the worker processes assigned to an application pool are found to be unhealthy within a specified period of time.

Some Web sites and applications have memory leaks, are poorly coded, or have other unidentified problems. In IIS 5.0 isolation mode, these applications can force you to restart the entire Web server. The recycling feature in worker process isolation mode can periodically restart the worker processes in an application pool to manage faulty applications. Worker processes can be scheduled to restart based on several options, such as elapsed time or the number of requests served.