Introduction (Web and Application Server Infrastructure - Performance and Scalability)

Applies To: Windows Server 2003 with SP1

Microsoft Windows Server 2003 incorporates a significantly different Web and application server infrastructure than previous releases of Windows Server. In fact, the key theme of the release is to bring forward the fundamental capabilities of the Web application platform, with a view to laying a solid foundation for existing and future server-based Windows .NET Framework applications and Web services.

A key part of bringing forward the fundamentals of the platform is to also provide significant business benefit for existing applications and Web sites currently running on Microsoft Windows NT 4.0 and Windows 2000, when migrated to Windows Server 2003. An increase in capacity and/or scalability for these applications can be valuable from a Total Cost of Ownership (TCO) perspective (by decreasing the number of servers used or by improving capacity on existing servers). In addition to ensuring that Windows Server 2003 was optimized for Windows .NET Framework applications, specific engineering effort was put into ensuring that existing ISAPI and ASP/COM+ applications would also see a performance and scalability gain on Windows Server 2003. This paper covers performance tuning considerations for ISAPI and ASP/COM+ applications, in addition to providing tuning ideas for the Windows .NET Framework.

Audiences for This Document

This document is intended for operations staff, IT administrators, developers, and architects. It is broken out into four main sections:

1. Architectural Discussion on Web performance features and capabilities of Windows Server 2003

2. Programming Considerations

3. General Performance Considerations

4. Application Scenarios

For all audiences, the architectural discussion section is a useful primer. It lays the foundation and introduces concepts elaborated on in the rest of the paper.

Developers and architects should then focus on the Programming Considerations section, followed by the General Performance Considerations section.

IT administrators and operational staff should approach this paper from either the Application Scenarios section (selecting whichever scenario applies), or the General Performance Considerations section.

Performance and Scalability a New Architecture

From the outset, the attributes of performance and scalability were some of the key drivers pushing the new application model and design tradeoffs in Windows Server 2003 development.

Much of the application server functionality in Windows is layered on top of Internet Information Services (IIS)1. This discussion will begin with a comparison of IIS architecture past and present.

Figure 1: IIS 5.0 (Windows 2000) processing architecture

IIS 5.0 was designed to have one process, Inetinfo.exe, be the main Web server process which could farm requests out to one or more out-of-process applications, DLLHost.exe (Figure 1). In comparison, IIS 6.0 has been redesigned into three new components, which allows IIS to segment Web server code from application handling code. These three new components are: a kernel-mode HTTP listener, called HTTP.sys; a user-mode configuration and process manager, called the WWW Service Administration and Monitoring component; and the application handler, which is loaded into each worker process2. These worker processes, in turn, service requests for application pools3 in HTTP.sys.

HTTP.sys and Kernel-Mode Queuing

In this new architecture, regardless of what happens to the user mode custom application, the IIS 6.0 kernel component preserves established TCP/IP connections. Therefore, if a rich client application connects to a Web service running on Windows Server 2003, and the Web service (for whatever reason) crashes or throws a fatal exception, IIS 6.0 will maintain the TCP/IP connection and restart the application. It is unlikely that these events will be noticed by the end user (or network load balancers/switches), as the client connections will be preserved.

Windows Server 2003 introduces a new kernel-mode HTTP driver called HTTP.sys, which is specifically tuned to increase Web server performance and scalability. In IIS 6.0, HTTP.sys listens for requests and routes them to the appropriate requests queue. Each request queue corresponds to one application pool. Because no application code runs in HTTP.sys, it cannot be affected by failures in user-mode code that normally affect the status of the Web service. If an application fails, HTTP.sys continues to accept and queue new requests on the appropriate queue until one of the following: the process has been restarted and begins to accept requests, there are no queues available, there is no space left on the queues, or the Web service itself has been shut down by the administrator. Once the WWW service notices the failed application, it starts a new worker process if there are outstanding requests still waiting to be serviced for the worker processs application pool. Thus, while there may be a temporary disruption in user-mode request processing, an end user does not experience the failure, because requests continue to be accepted and queued.

WWW Service Administration and Monitoring Component

The WWW Service Administration and Monitoring component makes up a core portion of the WWW service. Like HTTP.sys, no application code runs in the WWW Service Administration and Monitoring component. This component has two primary responsibilities: system configuration and worker process management.

At initialization time, the configuration manager portion of WWW service uses the in-memory configuration metabase4 to initialize the HTTP.sys namespace routing table. Each entry in the routing table contains information that routes incoming URLs to the application pool that contains the application associated with the URL. These pre-registration steps inform HTTP.sys that there is an application pool that responds to requests in a particular part of the namespace, and that HTTP.sys can request that a worker process be started for the application pool when a request arrives. All pre-registrations are done before HTTP.sys begins to route requests to individual processes. As application pools and new applications are added, the Web service configures HTTP.sys to accept requests for the new URLs, sets up the new request queues for the new application pools, and indicates where the new URLs should be routed. Routing information can change dynamically without requiring a service restart.

In the worker process management role, the WWW Service Administration and Monitoring component is responsible for controlling the lifetime of the worker processes that process the requests. This includes determining when to start, recycle, or restart a worker process, if it is unable to process any more requests (becomes blocked). It is also responsible for monitoring the worker processes, and can detect when a worker process has terminated unexpectedly.

Worker Process Isolation Mode

Figure 2: IIS 6.0 (Windows Server 2003) processing architecture

IIS 6.0 introduces a new application isolation mode for managing the processing of Web sites and applications: worker process isolation mode (Figure 2). Worker process isolation mode runs all application code in an isolated environment (W3wp.exe) without incurring a performance penalty for that isolation. Requests are pulled directly from the kernel instead of having a user-mode process pull them from the kernel for the application, and then route accordingly to another user-mode process as was the case in IIS 5.0. First, HTTP.sys routes Web site and application requests to the correct application pool queue. Then, the worker process(es) (W3wp.exe) serving the application pool pull requests directly from the application queue in HTTP.sys. This model eliminates the unnecessary process hops encountered when sending a request to an out-of-process DLLHost.exe and back again (as was the case in IIS 4.0 and 5.0), and increases performance.

In worker process isolation mode, administrators can isolate different Web applications or Web sites into separate application pools. Each application pool is separated from other application pools by process boundaries. For example, a departmental server might have Web-HR in one application pool and Web-Financing in another; an Internet Service Provider (ISP) might have https://www.adventure-works.com in one application pool and https://www.blueyonderairlines.com in another. An application that is assigned to one application pool is not affected by other application pools, and cannot be assigned to another application pool while being serviced by the current application pool. Note that applications can be easily assigned to another application pool while the server is running.

It is important to note that, in IIS 6.0, there is no longer any notion of in-process applications. All necessary HTTP application run-time services, such as ISAPI extension support, are equally available in any application pool. This design prevents a malfunctioning Web site or application from disrupting the operation of other Web applications or the server itself. With IIS 6.0 it is now possible to unload in-process components without having to take down the entire Web service. The host worker process can be taken down temporarily without affecting other worker processes serving content. There is also a benefit from being able to leverage other operating system services available at the process level (for example CPU throttling), per application pool. Additionally, Windows Server 2003 has been re-architected to support many more concurrent processes than ever before.

Worker process isolation mode prevents one application or site from stopping another. In addition, separating applications or sites into separate application pools simplifies a number of management tasks, for example: taking a site/application online or offline (independent of all other site/applications running on the system), changing a component the application uses, debugging an application, monitoring counters for an application, and throttling resources used by an application.

The IIS 6.0 request processing architecture delivers very high levels of reliability without sacrificing performance.

• Increased reliability. IIS 6.0 worker process isolation mode prevents Web sites and applications from affecting each other or the server as a whole.

• Fewer server restarts. The user will likely never need to restart the server or shut down the entire WWW service, due to a failed application or common administration operations, such as upgrading content or components, or debugging Web applications.

• Increased application availability. IIS 6.0 supports auto restart of failed applications and periodic restart of leaky/malfunctioning applications, or applications with faulty code.

• Increased scalability. IIS 6.0 supports scaling to ISP scenarios, where there may be hundreds to thousands of sites on a server. IIS 6.0 also supports Web gardens, where a set of equivalent worker processes on a server each receive a share of the requests that are normally served by a single worker process.

• Strong application platform support. IIS 6.0 supports the application as the unit of administration. This includes making the application the unit of robustness by enabling application isolation, and also enabling resource throttling and scaling based on the application.

The end result is a Web platform that is more reliable and always available even if applications cause their worker processes to terminate. Worker process isolation mode contains the following features which improve its robustness without a performance impact.

Clean Separation Between User Code and the Server

All user code is handled by worker processes, which are completely isolated from the core Web server. This improves upon IIS 5.0, because an ISAPI can be, and often is, hosted in-process to the core Web server. If an ISAPI loaded in a worker process fails or causes an access violation, the only thing taken down is the worker process that hosts the ISAPI. Meanwhile, the WWW service creates a new worker process to replace the failed worker process. The other worker processes are unaffected.

Multiple Application Pools

With IIS 5.0, applications can be pooled together out-of-process, but only in one application pool, which is hosted by DLLHost.exe. When IIS 6.0 operates in worker process isolation mode, administrators can create up to 2,000 application pools, where each application pool can be configured separately.

WebGardens

Multiple worker processes can be configured to service requests for a given application pool. By default, each application pool has only one worker process. However, an application pool can be configured to have a set of N equivalent worker processes that share the workload. This configuration is known as a Web garden because it is similar in nature to a Web farm, the difference being that a Web garden exists within a single server. Requests are distributed by HTTP.sys among the set of worker processes assigned to the application pool. The distribution of requests is based on a round-robin scheme, where new connections with requests for the application pool are assigned to specific worker processes in that application pool. A benefit to Web gardens is that if one worker process slows down, such as when the script engine becomes unresponsive, there are other worker processes available to accept and process requests.

Processor Affinity

Worker processes can have an affinity to specific CPUs to take advantage of more frequent CPU cache (L1 or L2) hits. Processor affinity, when implemented, forces IIS 6.0 worker processes to run on specific microprocessors or CPUs and applies to all worker processes serving the Web sites and applications of an application pool. Processor affinity can also be used with Web gardens that run on multiprocessor computers where clusters of CPUs have been dedicated to specific application pools. Organizing workloads on a CPU means a more efficient usage of the CPU resources.

Demand Start

The new IIS architecture offers the benefit of demand start. Demand start means that the server is listening on an applications request queue, but will not physically initialize the application until a client has specifically connected to the application and requested service. At that point, a worker process will be initialized and the request will be fed into the processing engine for that application.

The WWW Service Administration and Monitoring component does on-demand process starting, and generally controls and monitors the lifecycle of worker processes.

Idle Time-out

The converse side of demand start is idle time-out. If an application has not had a request arrive for a configured amount of time, it can help to optimize a system if the resources that the application was using are temporarily freed up, until a client decides to use the application at some later point in time.

Idle time-out does not mean that the application is offline (i.e., the applications network endpoint is still active) just the physical process and run-time environment for the application are given back to the operating system.

Kernel-Mode Caching

Kernel-mode caching is available when using IIS 6.0, both in worker process isolation mode and in IIS 5.0 isolation mode (see below). As a single point of contact for all incoming (server-side) HTTP requests, HTTP.sys provides high-performance connectivity for HTTP server applications and provides overall connection management, bandwidth throttling, and Web server logging. IIS 6.0 has been built on top of HTTP.sys and has been specifically tuned to increase Web server throughput. In addition, under specific circumstances, HTTP.sys directly processes requests in the kernel. Both static and dynamic content from Web sites and applications can be cached in the HTTP.sys cache for high-performance responses.

IIS 6.0 has advanced heuristics built in to determine the cacheable hot-set of an application or set of sites. Just because an item is cacheable, does not necessarily mean it makes sense to add that item to an in-memory cache, since there is a cost to managing the item and the memory it consumes. Therefore, IIS 6.0 uses a new heuristic to determine which items should be cached on the basis of the distribution of requests that a particular application receives. This means that the Web server makes better use of the resources available, while sustaining the performance on frequent requests, leading to scalability improvements.

IIS 6.0 also has heuristics built in to monitor the overall state of the server, and makes decisions to increase or reduce concurrency on that basis. The central idea here is to be efficient in using concurrency. For example, when executing processor-bound requests, starting concurrent work is not always the best approach.