Architecture

If you take a closer look at how previous versions of IIS have worked, you can see that IIS has always being trying to ice-skate uphill. The primary problem with IIS 5 and lower is that it was always a bolt-on attachment to the original operating system?although it was integrated into the security systems, operated as a service, and it was never truly an operating system component, such as the file service or active directory.

To add complications to this, the very nature of supporting Web applications means that you are immediately open to potential abuse from programmers and Web designers. Supporting most Web applications relies on using untrusted, third-party applications, often written by inexperienced programmers even when developing within a corporate environment.

The effect is to introduce a number of largely uncontrollable problems:

Stability? If an application supported through IIS crashes, the chances are that either it will crash IIS or it will 'steal' resources from other Web sites and applications.

Security? If the application provides a method for accessing the application in a nondocumented fashion, you have a potentially lethal security breach that could be used to access your entire network.

Performance? One top-heavy process has to deal the majority of the processing because a rogue user-mode application could be sapping CPU and memory from the other requests. Performance can be significantly impaired.

Scalability? Because a single process is responsible both for accepting and processing many of the requests, clients can be waiting to communicate a request while another user is still being serviced. When scaling up to multiple processors or machines, the same basic bottleneck remains.

Integration? Although previous versions gave the impression of being integrated into the OS, the reality is that IIS was just another application.

The solution within IIS 6 is to separate the two core stages in any HTTP request, the actual request and the response, and provide protected and independent areas for executing user sourced applications. This first component, the HTTP request mechanism, is supported by HTTP.sys?otherwise known as the Kernel Mode Driver. The second stage, the processing of the request and the response, is handled by a new system, called the application pool, which is in turn serviced by one or more worker processes.

A second component, WWW Service Administration and Monitoring, then monitors both the kernel mode driver and the worker processes and enables you to monitor their status. It can also automatically reassign and manage the individual processes so that a failure in one application can be remedied without interrupting another request and without end users being aware of any problem.

These overall changes to the way in which IIS 6 handles requests have provided us with two different modes of operation?Worker Process Isolation Mode, the default, and IIS 5 Isolation Mode, a backward compatible mode most useful for migration. Both use similar components, but in different ways, so we'll look at each solution separately.

Worker Process Isolation Mode

To get a better idea of how the new architecture works, look at Figure 2.1. It shows how requests for information are processed.

The HTTP.sys kernel mode driver waits for incoming requests. When a request from a client is received, one of two things happen:

• The request is handed off to the appropriate request queue within one of the configured application pools.

• The request is handled internally by the HTTP.sys driver for information that is cached when kernel mode caching has been switched on.

Application pools are assigned to process requests for individual sites, URLs, or dynamically based on loading. For example, Figure 2.1 illustrates two application pools?Pool A could be configured to process queries for the URL http://www.mcslp.pri, whereas Pool B processes requests for http://admin.mcslp.pri.

By transferring the request to one of the queues, it immediately frees up the HTTP.sys driver to accept another request from a client and process it accordingly. The bottleneck from the old request processor, which did both jobs, has been eliminated by making the primary point of contact merely a marshaling tool. This increases the number of requests that can be processed by the server without requiring any physical improvements to the machine, just through better management of the requests themselves.

Each application pool is in charge of a number of worker processes. These processes in turn handle the authentication and authorization and ultimately execute the underlying ISAPI filter or application to process the next request from the queue. Application pools work independently of each other, and worker processes within a pool work independently of each other, as well.

We'll look at each component in more detail so you can understand the underlying configuration and administration requirements for each section.

HTTP.sys (Kernel Mode Driver)

HTTP.sys is a kernel level driver, and it's responsible for just one thing?listening for incoming requests on a given IP address and port for incoming HTTP queries. After the request has been accepted, it's placed into the appropriate request queue, and HTTP.sys returns to process the next request.

The basic premise of HTTP.sys is to accept and process the incoming request from a client as quickly as possible to achieve the highest possible client connection acceptance rate. In standard operation, that means handing off the connection to the appropriate application pool. But if kernel mode caching has been enabled, the data is returned directly to the client without any further disk access or application execution.

Because HTTP.sys operates at the kernel level, it has a higher priority than most user-mode processes and it has direct access to the TCP/IP driver stack. Also, as a kernel driver, it is incapable of processing user-level code, thus making it impossible for any user-level code, such as that used by one of the assigned application pools, to cause the primary point of client contact to fail or stop accepting requests.

HTTP.sys is also responsible for all text-based logging for the WWW service. Because it is the primary contact point, it is the obvious choice and it enables IIS to log requests as soon as they have been received without having to wait for the response from the corresponding user application.

Finally, HTTP.sys is responsible for implementing the Quality of Service (QoS) functionality, which controls the core connectivity parameters, such as connection limits, timeouts, queue lengths, and bandwidth throttling.

Application Pools

The application pool is a highly configurable element of the user-mode component of servicing HTTP requests. Each application pool consists of one request queue, which holds the incoming client requests passed on by HTTP.sys, and one (or more) worker process that services those requests.

Each application pool is separated from other pools through the use of a separate process for each pool. Application pools are handled in user mode, naturally separating them from the kernel mode driver HTTP.sys and also making them more easily configurable and manageable.

Individual applications can be assigned to a single application pool, and one application pool can service the requests of multiple applications. However, you cannot assign a single application to use more than one application pool?to improve performance, you instead increase the number of worker processes servicing the requests.

Application pools, like the rest of the system, are monitored, and it's possible to configure individual pools to handle their worker processes in a number of different ways. For example, you can configure one application pool to continually renew each worker process after a set number of requests or perhaps after a set period of time.

This particular model of application pools improves on the original concept of isolation introduced in IIS 4 and builds on the application namespace solution in IIS 5. The overall effect provides the following benefits:

Clean separation between the user and kernel code? It's now impossible for a derived application to bring down the entire IIS service. Instead, either only the application pool will be brought down, or more likely, the worker process causing the problem will be restarted by the monitoring service.

Multiple application pools? They make it much easier and efficient to host multiple sites on a single server. For companies (particularly ISPs) that support a number of clients on a single server, you can configure separate pools on a per-client or even per-site basis without fear of upsetting other client's hosting stability.

Worker process management? Worker processes are monitored and managed so that it's impossible for a worker process to halt the entire server. You can configure an application pool only to create a worker process when it's required by the application pool, reducing long-term resource use?ideal for low traffic sites or those that are used only at specific times. Furthermore, a timeout can be set when the process will be terminated if it hasn't been used.

Rapid-fail protection? If the worker processes in an application continually fail, the WWW service can take the application out of service, reporting error 503 (Service unavailable) to further client requests.

Load balancing support? The application pool concept works perfectly with load balancing technologies. Now it's possible to distribute requests within the same server with the same level of application separation that was previously only available across a number of machines.

Request Queues

The request queue handles the incoming requests supplied by HTTP.sys waiting to be processed by the corresponding application pool. One request queue exists for each pool. However, the request queue is not a marshaling service as such; it just provides a place for requests to be queued. It is the responsibility of individual worker processes to apply for requests from the queue to work on.

Worker Processes

Worker processes answer individual requests as part of an application pool. Each worker process, an instance of the W3wp.exe application, runs in user mode and is therefore separately manageable and monitored by the WWW Service administration and monitoring component.

Worker processes are solely responsible for invoking an ISAPI filter (including ASP and ASP.NET) or running a CGI handler when working with CGI-based applications.

Individual worker processes also handle authentication and authorization, and this ties in with the default authorization level of the worker process applications. By default, worker processes run as NetworkService, which has the strongest security (and therefore the least default access).

Because worker processes operate independently of the system that accepts the requests from the client, we can manage and control the worker processes to solve performance and reliability problems. Through the application pools, we can also control the availability, responsiveness, and performance of individual applications.

In fact, worker processes are highly configurable. Here are some of the main elements that can be tuned and their benefits:

Health monitoring? We can monitor individual worker processes, creating, killing, and restarting them according to the settings of the application pool?improving stability and freeing up resources when worker processes are not required.

Processor affinity? You can assign individual worker processes to specific processors within an SMP system, either to make the best use of the available processor resource or to take advantage of better L1 or L2 caching in each processor. Such fine control can make a real performance difference with some applications.

CPU monitoring? Individual worker processes can be limited to specific amounts of CPU time, allowing you to efficiently distribute your CPU time between application pools, worker processes, and, ultimately, clients.

Demand start? The monitoring system can dynamically create a worker process when the application pool receives a request. By not permanently keeping worker processes running, the resources can be used by other applications and processes in the system.

Idle timeout? Linked to the Demand Start feature, we can also kill off worker processes that identify themselves as idle, freeing up those vital resources.

Orphan control? If the WWW monitoring service identifies a worker process that is causing serious problems, but not necessarily dead or failed, it can either kill or orphan the process. This involves killing and then restarting the worker process to prevent its state affecting the operation of the pool. When orphaning is enabled, the killed process continues to execute, but a new process is started to handle requests. You can also configure orphans to be automatically debugged.

Manual recycling? To prevent worker processes from 'going stale,' eating up resources, or for those applications suffering from hard to identify problems, individual worker processes can be recycled (killed and recreated). This can be done without affecting the availability of the Web site.

Automatic recycling (restarting)? As an extension of the manual recycling, worker processes can also be automatically recycled based on

• Elapsed time

• Number of requests served

• Scheduled time within a 24-hour period

• Result of a 'liveliness ping'

• Virtual Memory usage

• Physical Memory usage

As with the manual process, this recycling happens in the background without affecting the execution or availability of the site. HTTP.sys will continue to accept and queue requests, and those requests waiting in the queue will be processed as soon as a worker process becomes available.

WWW Service Administration and Monitoring Component

By now it should be clear that the WWW Service Administration and Monitoring Component (WSAMC) provides a critical part of the overall system. The WSAMC component handles two main areas?configuration and process management.

When IIS 6 starts, the request process manager portion of the WSAMC, which is responsible for distributing requests, loads the IIS metabase. The WSAMC then creates the routing table, which associates a specific URL with one of the configured application pools, and this is used to redirect requests received through HTTP.sys.

Then, the WSAMC system notifies HTTP.sys of the different request queues and routing parameters that ultimately enable the Web service. Changes to the metabase, either directly or through the IIS MMC snap-in, update the routing table, and HTTP.sys is updated with the changes.

When the system is up and running, the request processor in the WSAMC is responsible for managing the individual worker processes, including starting, stopping, and recycling processes, as well as also monitoring and recycling those processes that have failed if necessary.

Web Application Isolation

As the name suggests, the idea of Worker Process Isolation mode is to isolate user-mode operations into one or more application pools and in turn, one or more worker processes?all completely separate and also separate from the primary contact point, HTTP.sys.

You can see this isolation more clearly if you refer back to Figure 2.1. Application Pools 2 and 3 are single worker process pools, whereas Pool 1 is a Web garden pool. A failure in Pool 2 will not affect the other two pools. More importantly, it's unlikely that a failure in a single worker process in Pool 1 would have a significant affect on the other worker processes.

Because of this isolation, when IIS 6 works in this mode, you get an effective combination of stability and performance. The stability comes from the way in which we can individually control each application pool and worker process, including the monitoring and automatic recycling of failed processes.

The performance improvements are introduced through the use of separate worker processes and application pools. Within the pools, we can tune the parameters to give specific response time and execution parameters. Using multiple worker processes, we can also spread the load of requests over one or more processes and ultimately individual processors, making use of SMP technology.

IIS 5 Isolation Mode

IIS 5 Isolation Mode was designed to retain compatibility with applications that are currently being supported under IIS 5 on Windows 2000. Unfortunately, this mode eliminates many of the features in worker process isolation mode, including application pools, worker processes, recycling, and the health monitoring features.

What doesn't change is the role of HTTP.sys as a kernel-level component for accepting requests from clients. You can see the model for this mode in Figure 2.2. The request model in this mode matches, almost identically, the request path of IIS 5.

You can see here that HTTP.sys handles the requests, but all requests are appended to the same, global request queue, which is used by all the other components and applications. There are no individual queues, and no way to configure requests at an individual application level.

The requests are handled by the WWW service, with Inetinfo.exe, the same application used in IIS 5/Windows 2000, handling the static requests and providing the execution environment for integrated ISAPI filters and extensions used in low-isolation Web applications.

Medium (pooled) and high-level applications are still handled with separate, out of process, application hosts through the DLLHost.exe application.

Web Application Isolation

IIS 5 Isolation Mode offers three different isolation modes for individual applications supported by IIS. These are similar to the modes in IIS 5:

Low (IIS Process) applications run 'in-process' within the Inetinfo.exe application and are not protected from other applications that are also running in-process. Applications execute using the default identity LocalSystem.

Medium (Pooled) applications run as DLLs within a single DLLHost.exe instance. These applications are protected from the effects of failures in both high and low applications, but not from failures from other applications in the same pool. Applications execute by default as IWAM_ComputerName.

High (Isolated) applications run as DLLS in DLLHost.exe and are both isolated from other applications, and other applications are isolated from them. Applications execute by default as IWAM_ComputerName.

Isolation Mode Comparison

You can quickly identify the main differences between the two application modes and which application services requests using Table 2.1. Note that because worker processes are responsible for running all ISAPI components, there is no such thing as an out-of-process ISAPI extension.

Default Settings

Depending on how you have installed Windows Server 2003 and IIS 6, the system will have automatically determined the default operation mode of your IIS 6 installation. Table 2.2 illustrates a quick overview.