다음을 통해 공유

Features of Worker Process Isolation Mode

  • 아티클

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

Worker process isolation mode includes several features that you can use to improve IIS robustness, scalability, and reliability without reducing performance. These features include multiple application pools, application pool health monitoring, worker process recycling, and rapid-fail protection. When you run your Web server in worker process isolation mode, you can configure application pools to take advantage of these features, which can only be used when a Web server is running in worker process isolation mode.

Multiple Application Pools

In IIS 5.0, applications can be pooled together out-of-process, but only in one application pool (typically referred to as a pooled out-of-process in IIS 5.0, rather than an application pool). In IIS 6.0, worker process isolation mode allows customers to create multiple application pools, each with a different configuration, such as a unique recycling configuration or a unique process ID. In addition, all HTTP application run-time features, such as the services that support ISAPI extensions, are available in all application pools. This design prevents a malfunctioning Web application or Web site from disrupting other Web applications or Web sites on that server.

Application Pool Health Monitoring

You can configure an application pool to monitor not only the health of its worker process, but the health of the entire pool. The WWW service can detect an unhealthy application pool in these situations:

  • If a worker process in the application pool terminates abnormally.

  • If all of the available IIS threads in the worker process that is assigned to the application pool are blocked.

  • If the application notifies IIS that a problem exists.

Monitoring the health of a worker process includes detecting that the worker process is not able to serve requests and taking corrective action. For example, if a worker process does not respond to a ping from the WWW service, the worker process probably does not have threads available for processing incoming requests. When this happens, the WWW service either terminates the worker process or releases the worker process and leaves it running. (You can configure IIS to attach a debugger to an unhealthy worker process when the WWW server releases it.) If requests are waiting in the request queue, the WWW service starts a new worker process to replace the one that was terminated or released.

For more information about configuring IIS for application pool health monitoring, see Configuring Worker Process Health Monitoring in IIS 6.0 Help and Running IIS 6.0 as an Application Server.

Worker Process Recycling

Web applications sometimes leak memory, are poorly coded, or have other unidentified problems. In earlier versions of IIS, these faulty applications might force you to restart the Web server. In worker process isolation mode, you can use the recycling feature to periodically restart the worker processes in an application pool in order to manage faulty applications. You can schedule worker processes to restart based on several options, such as elapsed time or the number of requests served.

You can configure the WWW service so that it recycles a worker process in one of two ways:

  • By default, the WWW service establishes an overlapped recycle, creating a new worker process to handle any new incoming requests before signaling the old worker process to finish processing its existing requests and shut down.

  • Optionally, the WWW service first signals the old worker process to shut down and, after it shuts down, starts a new worker process.

In both types of recycling, the WWW service allows a configured amount of time for the old worker process to handle the requests that it has already taken from HTTP.sys before it shuts itself down.

In the default configuration, when a worker process requests a recycle, the WWW service initiates an overlapped recycle, creating a new worker process to replace the old process. While the new worker process is starting, the old process continues to serve requests. As soon as the new worker process starts and initializes successfully, the WWW service signals the old worker process to shut down. The old worker process then stops pulling new requests and begins to shut down. The WWW service gives the old worker process a configured time period in which to finish processing its requests and shut down, and it terminates the worker process if it does not shut down within the specified time.

For more information about worker process recycling, including when to use it and how to configure it, see Recycling Worker Processes with IIS 6.0.

Rapid-Fail Protection

Rapid-fail protection stops an application pool when too many of the worker processes assigned to it are found to be unhealthy within a specified period of time. When an application pool is stopped, HTTP.sys either returns an out-of-service message (503: Service Unavailable) or resets a connection based on the configuration of the LoadBalancerCapabilities property of the application pool. Also, when an application pool stops automatically, such as when rapid-fail protection engages, you can configure an action (a debugging action, for example) to notify the administrator that the application pool has stopped.

For more information about rapid-fail protection, including how to configure this feature, see Running IIS 6.0 as an Application Server.

Orphaning Worker Processes

You can configure worker process isolation mode to orphan a worker process that the WWW service deems to be failing. The WWW service usually terminates a failing worker process and replaces it. If you enable orphaning, the WWW service allows a failing worker process to continue running, but separates it from the application pool (making it an orphan) and starts a new worker process in its place. You can configure the WWW service to run a command on the orphaned worker process — for example, launching a debugger.

For more information about orphaning worker processes, including how to configure this feature, see Running IIS 6.0 as an Application Server in this book and OrphanWorkerProcess Metabase Property metabase property.

Web Gardens

Web gardens are application pools that are configured to run multiple worker processes. By default, each application pool in IIS 6.0 has only one worker process. However, you can configure an application pool to have a set of equivalent worker processes that share the work, thus creating a Web garden. In a Web garden, HTTP.sys distributes the requests among the set of worker processes in the application pool.

Note

Do not confuse a Web garden with a Web farm, which is a Web site or Web hosting service that runs off of more than one server and that uses clustering and load balancing.

The benefits of Web gardens are that they can handle more load, and that if one worker process stops responding, other worker processes are available to accept and process requests. Hence, Web gardens can enhance performance and reliability of the applications in the application pool.

The MaxProcesses metabase property determines the maximum number of worker processes that an application pool allows to service its requests. For more information about Web gardens, including how to create them, see Running IIS 6.0 as an Application Server, and Configuring Web Gardens with IIS 6.0.

Processor Affinity

Processor affinity is an application pool property that forces worker processes to run on a specific set of microprocessors or CPUs. Processor affinity applies to all worker processes that serve a particular application pool and allows you to take advantage of more frequent CPU caching. If a Web garden is running on a multiprocessor computer, you can use processor affinity to dedicate certain application pools to specific clusters of CPUs.

To set up processor affinity, configure the SMPAffinitized and SMPProcessorAffinityMask metabase properties. For more information about assigning processor affinity, including how to configure these metabase properties, see Running IIS 6.0 as an Application Server.

Idle Timeout

You can configure an application pool to have its worker processes request a shutdown if they are idle for a certain period of time. Configuring idle timeout can help you to free unused resources. New worker processes are started when demand exists for that application pool.

Use either IIS Manager or the IdleTimeout metabase property to configure this feature. For information about setting the IdleTimeout metabase property, see IdleTimeout in IIS 6.0 Help. For more information about configuring idle timeout for a worker process, see Running IIS 6.0 as an Application Server.

Application Pool Identity

Application pool identity is the user account that the worker processes servicing the application pool use as their process identity. Process identity is the operating system term that is used to denote the account that a process runs under. Every running process on a Windows NT operating system has a process identity that is used to control access to resources on the system.

You can assign a predefined account for the application pool identity or create your own account for this purpose. For security reasons, choose an application pool identity with the minimum permissions that your application requires.

For more information about configuring process identities, see Configuring Worker Process Identities.