لطفا منتظر باشید ...
Moving from IIS 5.0 Isolation Mode to Worker Process Isolation Mode
IIS 6.0 can run in one of two distinct modes of operation, which are called application isolation modes. Application isolation is the separation of applications by process boundaries that prevent the applications from affecting one another, and it is configured differently for each of the two IIS application isolation modes: IIS 5.0 isolation mode and worker process isolation mode.
Before you begin deployment, review the following:
Differences between IIS 5.0 isolation mode and worker process isolation mode
Benefits of moving from IIS 5.0 isolation mode to worker process isolation mode
| Note | This book assumes that IIS 6.0 is running in worker process isolation mode, unless otherwise noted. |
Reviewing Application Isolation Modes
Worker process isolation mode uses the redesigned architecture for IIS 6.0. This isolation mode runs all application code in an isolated environment. However, unlike earlier versions of IIS, IIS 6.0 provides isolation without a performance penalty because fewer processor instructions are ran when switching from one application pool to another. Worker process isolation mode is compatible with most existing Web sites and applications. Whenever possible, run IIS 6.0 in worker process isolation mode to benefit from the enhanced performance and security in IIS 6.0.
IIS 5.0 isolation mode provides compatibility for applications that depend upon the process behavior and memory model of IIS 5.0. Run IIS in this mode only when a Web site or application cannot run in worker process isolation mode, and run it only until the compatibility issues are resolved.
| Important | IIS 6.0 cannot run both application isolation modes simultaneously on the same server. Therefore, on a single server running IIS 6.0, you cannot run some Web applications in worker process isolation mode and others in IIS 5.0 isolation mode. If you have applications that require separate modes, you must run them on separate servers. |
IIS 6.0 defaults to a different application isolation mode based on the type of deployment you select. For new installations and migrations, IIS is configured to run in worker process isolation mode by default. After you perform an upgrade from an earlier version of IIS, IIS is configured to run in IIS 5.0 isolation mode by default.
Before configuring IIS 6.0 to run in worker process isolation mode, evaluate whether your Web sites and applications are compatible with worker process isolation mode. In most cases, IIS hosts your Web sites and applications in worker process isolation mode without any problems. Nevertheless, determine application compatibility in your lab before deploying your IIS solution into production.
For more information about worker process isolation mode, IIS 5.0 isolation mode, and evaluating Web site and application compatibility with worker process isolation mode, see "Determining Application Compatibility with Worker Process Isolation Mode" in "Upgrading an IIS Server to IIS 6.0" in this book.
| Note | Identifying a complete list of potential incompatibilities that applications can experience with worker process isolation mode is beyond the scope of this book. Even after following the guidelines in this chapter, you still need to verify in your lab whether your Web sites and applications are compatible with worker process isolation mode. |
Benefits of Moving to Worker Process Isolation Mode
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.
In IIS 5.0, applications can be pooled together out-of-process, but in only one application pool. In IIS 6.0, worker process isolation mode supports multiple application pools, where each application pool can have a different configuration, such as a unique recycling configuration. Therefore, you can prevent a single Web site or application that periodically fails from disrupting other Web sites and applications. In addition, worker process isolation mode provides the following improvements to IIS.
Security Enhancements
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.
Default process identity for Web sites and applications set to NetworkService
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.
Performance and Scaling Enhancements
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.
Support for processor affinity for worker processes in an application pool
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).
Elimination of inactive worker processes and reclamation of unused resources
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.
Distributing client connections across multiple worker processes
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.
Ability to isolate Web sites and applications from each other
You can isolate Web sites and applications without incurring a performance penalty.
Availability Enhancements
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.
Reduced number of server restarts that are required when administering Web sites and applications
Many of the common operation tasks do not force the restart of the server or the Web service. 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 Web sites or applications on the server.
A fault-tolerant request-processing model for Web sites and applications
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.
Isolation of failed worker processes from healthy worker processes
In worker process isolation mode, IIS can determine that a worker process has failed and start a new worker process. To minimize the interruption of service, new requests are queued until the new worker process is active. In the case where a worker process has not yet failed but is considered unhealthy, IIS starts a new worker process. When the new worker process is active, IIS shuts down the unhealthy worker process. 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.
Health monitoring of Web sites and applications
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.
Prevention of Web sites or applications that fail quickly from consuming system resources
In some instances, 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.
Automatic restart of poorly performing Web sites and applications
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 without affecting service availability. Worker processes can be scheduled to restart based on several options, such as elapsed time or the number of requests served.
