IIS 6 Architecture

If you've worked with previous versions of IIS, you'll notice some significant improvements with IIS 6. Version 6 is designed to be much more stable and secure than previous versions. As you're going through this information, keep in mind that this is referring to the web server component of IIS. In IIS 6, FTP, SMTP, and NNTP still run in the inetinfo.exe process.

Previously in IIS (see Figure 1-6), everything ran in the inetinfo.exe process or out of process in dllhost.exe. An errant web site running in inetinfo.exe could take down the entire web service, causing an outage. IIS 6 separates web-server code from application- handling code with a kernel-mode HTTP listener, http.sys, and the Web Administration Service (WAS), which is a user-mode configuration and process manager (see Figure 1-7). These programs don't run any third-party code, so they can't be affected by an errant web site. The code is run in a worker process. These worker processes are run by the application w3wp.exe. Each copy of w3wp.exe is another worker process. These worker processes are separate from each other and from the kernel so that they can be isolated from the operating system.

Figure 1-6: Diagram of web server process-IIS 5

Caution 

In process refers to code that runs in the same process as the parent. Out of process refers to code that is run in a separate process.

Worker Process Isolation Mode

The IIS 6 web service runs all application code in an isolated environment. This is called Worker Process Isolation Mode. This type of functionality was previously available in IIS, but it inflicted a significant performance penalty. Since everything in IIS 6 is run out of process by design, there is no performance hit. Previous versions of IIS also relied on user mode processes to route requests to each other. In IIS 6, requests are pulled directly from the kernel, completely isolating worker processes from each other. This helps when two applications need to be isolated from each other for security reasons. For now, other IIS services (such as FTP and SMTP) still run in inetinfo, just as in IIS 5. Perhaps the next version will introduce worker process isolation for these services, but at the present time, they do have the ability to affect the inetinfo process.

IIS 5.0 Isolation Mode

Sometimes, worker process isolation can cause issues with applications that need to access data across instances or perform in an IIS 5 application pool environment. In this case, IIS can switch to what's called IIS 5 isolation mode. This mode operates like IIS 5 and allows these applications to perform in the IIS 5 application pool environment, while still allowing the kernel mode http.sys to queue and cache requests.

Figure 1-7: Diagram of web server process-IIS 6

Most web sites will work just fine under IIS 6, but a few events would force you to use isolation mode and abandon worker process recycling:

• Multi-instance ISAPIs that are written to be used multiple times simultaneously by different processes

• Read raw-data filters that would try to grab all the data before it hits a web site

• In-process session state variables, because they are lost every time a worker process is recycled

• Applications that farm out work to their own worker processes

Enabling IIS 5.0 Isolation Mode Enabling isolation mode must be done at the root level for the Web Sites folder in the IIS MMC. This is done for all web sites on this server as a whole-you cannot enable it on a per-web-site basis. Here's how it's done:

1. Open the IIS MMC.

2. Right-click the Web Sites folder and choose Properties.

3. Click the Service tab. Note that this tab is available only at this level.

4. Place a check mark in the box to Run WWW Service In IIS 5.0 Isolation Mode.

5. Click OK to return to the IIS MMC.

Application Pools

IIS introduces a whole new way of handling applications. Application pools allow code to be run in an isolated environment. Each application pool is serviced by one or more worker process. When IIS starts, the Web Administration Service initializes the http.sys namespace routing table with one entry for each application. This routing table determines to which application pool an application should be routed. When http.sys receives a request, it asks WAS to start up one or more worker processes to handle that application pool. This isolation of processes makes the web server as a whole more stable.

Health Monitoring

The WAS is able to keep IIS healthy by keeping track of the worker processes and monitoring their health. It can control these processes to keep them from causing IIS to stop responding. WAS keeps track of worker processes by pinging them at periodic intervals. If a worker process fails to respond to a ping, WAS terminates the process and starts a new one. This enables the system to keep responding to requests, even when a worker process gets hung up. If a process crashes and the worker process hangs, http.sys will queue up the requests until WAS starts a new worker process to handle that application pool. The end user will experience a temporary loss of service with applications in that application pool, while the core web services and any other applications will continue to function.

Orphaning Worker Processes

WAS can also be configured to orphan a worker process instead of merely terminating it. This allows the bad worker process to be examined to determine what happened.

WAS can be configured to run a command on the worker process (such as a debugger) when it orphans a worker process. Worker processes can be periodically restarted in addition to being automatically restarted on failure. This allows the system to reduce the effect of memory leaks by periodically reinitializing the environment and returning that memory to the system. When WAS restarts a worker process, it creates a new worker process and tells the existing one to finish what it's doing in a certain time frame and then shut down. This allows the application to stay up, while refreshing the worker processes behind it. If the worker process does not shut down within the allowed time frame, it is terminated.

Worker processes can be restarted based on the following criteria:

• Elapsed time

• Number of requests

• Time of day

• Memory usage

• Idle time

• CPU time used

Scalability

Worker process isolation mode also allows for better scaling of the web server. Thousands of sites can exist on a server with this configuration. Each application pool can be throttled individually, limiting the individual application pool to a certain amount of processor time.

Web Gardens

Multiple worker processes can be set up to handle a single application pool. This is called a web garden. Web gardens allow for better multiprocessor scalability, since each worker process can have an affinity for a single processor, to increase the cache hits on that processor. If one worker process gets bogged down, the other ones can take up the slack. It also reduces the need to reboot the server, even when upgrading components, because the application pool can merely be restarted.

The number of requests that should be queued for each application pool can be set in http.sys when running in worker process isolation mode. When this limit is reached, new requests to the full application pool are not processed, and the user gets an HTTP 503 error.

Note 

For more details on application pools and these options, see Chapter 2.