Platform Enhancements
IIS 6.0 and Windows 2003 Server have made significant improvements on the Windows 2000 platform with such features as:
64bit Platform
The entire Windows 2003 Server family code base can be compiled for either 32bit or 64bit platforms.
IPv6 Support
Windows 2003 now implements a production ready, native TCP/IP version 6 protocol stack.
Granular file level compression
In previous versions of IIS, compression was implemented as an ISAPI filter and could only be enabled globally. It can now be configured at the file level.
Quality of Service via resource monitoring
QoS features for IIS 6.0 come in the form of connection limits, timed out connections, application pool queue limits, cpu throttling, bandwidth throttling and memory based process recycling.
Logging improvements
Logging improvements address issues such as international support, large sites, or troubleshooting by adding the following features:
- UTF-8 Logging support
- Binary Logging support
- HTTP Error status subcodes
Improved patch management
The patch process for IIS 5.0 was often a headache due to the downtime involved. This has been addressed in IIS 6.0, allowing for less downtime, and automatic patching. All IIS 6.0 application dlls have been compiled resource free to allow greater internalization and localization.
IIS 6 Architecture Overview
IIS 6.0 has several new features that dramatically improve reliability and scalability, such as a new process isolation model much like the worker process isolation mode of ASP.NET, stable request processing architecture, and a revamped and actively managed runtime. Performance improvements like kernel mode queuing and caching have been added. Kernel mode operation allows the system to react to the incoming requests much faster. IIS 5.0 was designed around one process architecture. The one process known as inetinfo.exe functioned as the Web server process. IIS 6.0, in contrast, was redesigned into two new components, the kernel mode HTTP protocol stack (HTTP.sys) and a user-mode administration and monitoring component. This newly designed architecture allows IIS 6.0 to separate the functionality and operational activity from the processing of application code, without sacrificing performance. The two key components in the IIS 6.0 architecture are:
HTTP.sys is a kernel mode protocol stack that queues and parses incoming HTTP requests and caches and returns application content. This component does not load any application code, making it more secure. HTTP.sys listens for requests and queues them as needed. There is a one-to-one relationship between request queues and application pools. HTTP.sys provides a more reliable method of handling requests, because it never executes any application code. HTTP.sys can not be affected by failures in user-mode application code that would normally affect the health of the Web service. HTTP.sys continues to accept and queue requests in the correct queue until one the following happens: the process has been respawned and begins to accept requests, there are no more available queues, all space has been expended in each queue, or the Web service has been shut down. Due to the nature of kernel-mode processing, HTTP.sys is a very efficient request processor.
WWW Service Administration and Monitoring is a user mode process and configuration manager that delegates server operations and monitors the execution of application code. Like HTTP.sys this component does not load or process any application code.
The WWW Service Administrator and monitoring services play two major roles in the IIS 6.0 architecture, server configuration, and worker process management. When the system is initialized, the configuration manager uses the memory resident configuration metabase to initialize the HTTP.sys namespace routing table. Each entry in this table contains reference information that routes incoming URLs to the application pool that contains the corresponding application code. These steps inform the HTTP.sys component that there is an application pool that responds to requests in a part of the namespace, and that prompts HTTP.sys to request a worker process be started for the application pool if any requests come in. All of this registration is done before HTTP.sys begins to route requests. This routing information can be changed dynamically without requiring a service restart.
Application pools
Applications pools are for managing Web sites and application code. Application pools are separated by Windows 2003 process boundaries. You can configure up to 2,000 application pools per server. An example configuration would be to have Customer A’s applications configured to run inside “Customer A Application Pool ” and Customer B’s applications configured for “Customer B Application Pool”. This provides each application with a significant operational isolation boundary. This allows application pools to operate independently of each other. A request from one application can not be routed to another application pool while being serviced by the current pool. Applications can, however, be reassigned to other pools while the server is running.
Worker process services and isolation
Worker process services are the second new feature we will discuss. This model will seem very familiar to you, if you have had exposure to ASP.NET’s process architecture. A worker process handles all application execution, including authentication and authorization, as well as ISAPI filter and extension loading. This new executable process is called W3WP.exe. When acting as the worker process manager, the www service is responsible for controlling the lifetime of all worker processes that are processing requests. This is very similar to the machine.config section #&060;processModel#&062;, but allows this information to be managed from a GUI interface ( figure 3 ). This management console allows us to configure options such as when to start or recycle a worker process, how many requests to serve before recycling, and what to do if the worker becomes blocked or unable to continue processing requests.
Figure 3.
IIS 6.0 supports an all new application isolation mode for processing application and Web sites. This is referred to as worker process isolation mode. This allows all application code to be executed in a completely isolated environment without suffering any performance penalty incursion. Requests are pulled from the kernel directly, instead of having a user mode process pull them into the process, and then recommunicate the information to another user-mode process. Transferring kernel objects is vastly faster than incurring interprocess communication performance hits. This completely eliminates the process hops encountered when sending a request to DLLHost.exe and returning it back again. It is noteworthy that there is no longer an in-process application. All application runtime services are supported equally. Again this reinforces the separation boundary that allows several Web sites and applications to run concurrently without adverse affect on each other. Another great feature of worker process isolation is that if a worker process has to come down, another can be spawned in its place to deal with subsequent requests. This had the added benefit of being able to support other OS level services such as CPU throttling.
Some features of worker process isolation include:
Recycling of worker process
When a worker process becomes unstable the monitoring service can automatically respawn processes based on pre-configured criteria such as elapsed time, process request limit, resource usage and on demand. This allows administrators and developers to troubleshoot and manage applications by reducing the amount of downtime caused by an error or faulty application.
Orphaning of worker processes
The monitoring service can mark worker processes gone awry for “orphaning”. It can start a new worker process in the place of the “terminally ill” worker process. The monitoring service can also run a command (like attaching a debugger) on orphaned processes.
Worker process time out
An application pool can be configured to shutdown a worker process to reclaim unused resources if the application has been idle for a specified amount of time. Additional worker processes will be created as demanded.
Multiple application pools
By allowing the configuration of 2,000 application pools, Microsoft has greatly improved the amount of concurrent processes that can run without adverse affect on server health. Each application pool can be configured separately.
Better partitioning of applications across clustered environments
The advent of application pools creates a very real physical boundary between applications. This allows for a greater deal of isolation and flexibility.
Web garden support and processor affinity
Multiple processes can be configured to service requests for individual application pools. By default each application pool has only one worker process but can be configured to support x number of processes. This is referred to as a Web garden because it is similar in nature to a Web farm, but the difference being that it is localized to one single server. The worker processes respond to requests in round-robin fashion. The benefit comes from having multiple worker processes being able to process requests even if an application service (such as the scripting engine) becomes unresponsive. Tying a particular process to a specific CPU is also available as an option.
Kernel mode caching
By providing a high performing request broker running in kernel mode, IIS 6.0 is able to achieve a previously unparalleled level of efficiency. HTTP.sys has been tuned to boost performance on both static and dynamic contents.
Benefits of new request processing architecture include: fewer restarts, increased stability and reliability, higher application availability, and strong application platform support.