Worker process isolation mode provides an easy way to insulate Web applications from each other, so that problems with one Web application don't impact the other Web applications on Microsoft Internet Information Services (IIS).
IIS 6.0 allows you to organize applications into application pools. Each application pool is a completely independent entity, served by one or more worker processes. Usually, a Windows administrator will create a separate application pool for each Web application that the server hosts -- but a single application pool can host multiple applications.
Of course, this raises the question of how application pools can isolate IIS Web applications from each other. True isolation is possible because Windows differentiates between code that is running in kernel mode vs. code that is running in user mode.
Windows runs core IIS components, such as HTTP.SYS and the WWW service, in kernel mode. Each application pool contains its own kernel-mode queue. This means that HTTP.SYS is able to route inbound requests directly to a queue that is dedicated to a specific application pool, all within kernel mode. Application pools are separated from each other by process boundaries.
Worker processes are dedicated to a specific application pool to actually service requests. If a failure occurs, it usually happens within a worker process. However, since worker processes are bound to particular application pools, a worker process failure will only affect the application in which it resides, but no others.
The really cool part is that IIS provides mechanisms for monitoring the health of a worker process. If a worker process fails, the process can be restarted without the end user even being aware of the failure.
This is possible for two reasons:
- Application pools are not limited to using a single-worker process. If an application pool is configured to use multiple worker processes, then the failure of one worker processes does not affect the other worker processes within the application pool. The other worker processes continue hosting the application.
- Worker processes are not directly linked to inbound requests. For example, if a Web site had only one worker process and it failed, HTTP.SYS would continue to send requests to the application pool's dedicated queue. Without the worker process being operational, the queued requests can't be serviced, but the server is not flat out rejecting the requests either.
If Internet Information Services detects that a worker process has failed, it will simply restart the worker process (this is known as recycling). The entire process usually occurs within seconds, and then the worker process begins processing the queued requests once again.
In addition, to isolating worker processes from each other, the Internet Information Services architecture provides options for further limiting the effects of worker processes on the rest of the system. There are options for binding worker processes to specific processors on servers with multiple CPUs. You can also limit the amount of memory that worker processes consume.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server, Exchange Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. He writes regularly for SearchWinComputing.com and other TechTarget sites.
