Server Consolidation Scenario (Web and Application Server Infrastructure - Performance and Scalability)

Applies To: Windows Server 2003 with SP1

The Server Consolidation scenario is a special case of dense hosting in that the goal of this scenario is to put several unrelated Web applications or Web services on the same server. The big distinguishing factor is that in the Server Consolidation scenario, typically, the applications have much higher reliability requirements. Additionally, the applications will typically have higher request rates and there will be fewer applications per server than the Dense Hosting scenario.

Server consolidation is becoming more and more popular; it is quite common to find companies having many servers running a single application. Even though many of these applications are mission critical, they do not have high request rates or large processor or memory needs. In fact, they barely use the resources available to them on the servers they are running. The management cost of these servers can be improved proportional to the number of operating system instances being managed. Therefore, by consolidating these applications on a single server, a company decreases management costs and sometimes gets better operational management of the remaining operating systems.

Note

The following discussion will focus on the homogeneous consolidation of Web applications and services, not the heterogeneous consolidation of Web applications with e-mail, database, etc. This discussion does not focus on the versioning and side-by-side considerations of the server consolidation scenario.

Considerations

This section contains considerations relevant for tuning Windows Server 2003 in an (Web application) Consolidation scenario.

Independent Application Pools and Independent IIS Sites for Applications

This is a very likely configuration option in a Server Consolidation scenario. Given the reliability needs of applications, having them in separate application pools isolates failures and outages due to other applications. Applications can be managed separately; if they have bugs, they only have an impact on themselves, they can be put out of service for maintenance independently, without affecting other applications still online.

Having different applications or Web services running in their own application pool is also useful from a performance tuning perspective. Many settings are based on the application pool setting properties.

Independent Sites

The other setup configuration option, besides separate application pools, for a server consolidation scenario, is to have separate applications (or Web services) placed into separate IIS sites (Figure 10). There are additional settings and properties that can be controlled which are set at the site level. Examples include compression, bandwidth throttling, and total allowable connections to an application.

Creating an independent site for each application is simple. Each application must be accessed through a separate TCP/IP address, server port, or DNS name. The preferred approach is to use a separate DNS name per application, as this is much more efficient than using a separate IP address. Using a separate server port makes accessing applications a little more tedious (the port must be appended to all requests) when users are using a browser to access applications. If the application in question is a Web service, this is not as great a concern, since the separate port is usually ed away by a rich client or other program calling into the Web service.

d3e41b80-1f71-4433-8e54-c74bf683f965

Figure 12: Site, application, and Web service isolation capabilities

Resource Control

The application pool construct allows many settings to be applied per application. Many of these settings are resource controlled, but they also have performance impacts.

CPU

This is a primary resource control performance tuning parameter. The CPU utilization control available on the application pool object controls what percentage of the total CPU of the server that specific application gets.

The CPU control on the application pool object is the average amount of CPU the application should consume over unit time. So, if the CPU control on an application pool is set to CPU Utilization: 20%, for Time: 4 minutes, and an application consumes 40 percent for 2 minutes, the action for the application pool is fired. That means that if the application pool is set to Shutdown (should the CPU utilization be exceeded), the application pool will be shut down for 4 minutes, until the next period determined by the CPU occurs. Then, the application pool will be reactivated. If the action is set to No action, the excessive utilization will log an event in the system event log.

It is also possible to control the CPU utilization of a specific application in a server consolidation scenario, by configuring affinity between a processor and an application. For a discussion of affinity and large multiprocessor servers, see the Multiprocessor section (above). By establishing affinity between a specific application and CPU, you automatically limit the CPU available to an application. For example, if you are running on a 16-processor server, and the application has affinity with 4 processors, the maximum CPU that application has access to is 25 percent42.

Note

Notice that the default IIS capabilities do not allow true throttling of the CPU on an application pool. For throttling, see the Windows System Resource Manager Tool discussion below.

Memory

Memory utilization is an important performance parameter of an application. IIS 6.0 allows for the control of the memory utilization on a specific application, by limiting the Private memory and Virtual memory threshold settings. If these parameters are set too low, and the application exceeds the threshold frequently, the application will be recycled every few minutes, which will have a performance impact, given the system overhead of spinning up and warming up new processes and libraries.

In a server consolidation scenario, it is a good idea to have some excessive capacity on the server where you first place an application. Give the application an above-average amount of resources and monitor it for a few days, under normal usage. This will give an impression of the resource needs of the application. Then, select the resources you expect to constrain on the application and constrain them one by one. All the while, continue measuring the impact of the change, by assessing if the average response time of the application has increased. If so, you may have set one of the resources too aggressively for the application.

Identity

This is another property set on a per application pool basis. If set as a domain account, there will be slightly higher latency when starting processes, given the additional latency involved with communicating with a domain controller to log on the base process identity. This doesn’t mean that the identity will be accessed per request, only at process startup.

Logging

This is an important consideration in the Server Consolidation scenario. The decision is between having a single log file for all the applications on the server or having a separate log file per application.

Having a single log file per server is efficient if it is getting many requests (high throughput rate), because the centralized binary log file allows administrators to place the log file on a separate device dedicated to logging. That style of logging is most efficient: the disk subsystem gets to optimize its writes for the one, sequentially-written log file. The downside with the centralized binary log file is the need to use the LogParser utility to separate out log entries for specific applications (all applications on the server have their log items in the same file). For more information, see the New Format in IIS 6.0 Centralized Binary Logging section (above).

By contrast, leaving the standard logging on will generate a separate log file for every site on the server, but this could also mean high disk latencies in a disk I/O subsystem. The determination is largely dependant on the operational policy, the needs of logging in the environment, and the request rate experienced by the server.

To better understand the behavior and performance consideration of the Logging subsystem, see the Logging section (above).

Data Bandwidth Throttling

This can also be a key consideration when supporting many important applications on a single, physical piece of hardware. It is good practice to understand the total bandwidth available on the server and to restrict applications in terms of the maximum bandwidth they can use on a server.

This is not a reservation scheme; an application is not guaranteed that amount of bandwidth, each application (or site) is limited in terms of how much bandwidth they can consume. Further, just because the network devices in a server have published data rates, does not mean it is possible to achieve that data rate given the limitation of the number of physical cards on a root bus, and the speed of the bus. For a deeper discussion of the capabilities and considerations of the networking subsystem of an Internet server, see the Networking section.

Windows System Resource Manager (WSRM)

WSRM also allows you to manage CPU and memory utilization on a per application basis, but it provides a mechanism for implementing rich application policies and integrating them with a schedule. This means that an administrator can run multiple applications on a server with greater safety.

WSRM policies can be applied according to a time/date schedule. This allows administrators to free up CPU and memory for maintenance applications during non-peak hours, and for mission critical applications during peak hours.

The WSRM accounting feature allows administrators to generate, store, view, and export resource utilization reports for systems management, and service level agreement (SLA) tracking and billing purposes.

WSRM enhances the base IIS 6.0 by providing the ability to throttle the CPU use of a specific application pool. With WSRM, you can enable a situation where an IIS 6.0 application pool uses up to 20 percent of the CPU, regardless of the load coming in.

Tuning Parameters for Independent Applications

By placing separate applications in independent application pools, many of the control and tuning parameters are available to administrators when setting up the Server Consolidation scenario. IIS 6.0 allows many different Web application types to run side-by-side. For example, it is possible to take an ISAPI application, ASP/COM+ application, ASP.NET Web application, ASP.NET Web service, and a third-party application environment44, and run them all concurrently, side-by-side, on IIS 6.0.

Note, however, that for some of the Microsoft application technologies, additional configuration schemes contain some of the performance tuning parameters. For example, the ASP.NET technology also has a series of text files which contain configuration settings. The root configuration file for ASP.NET is the machine.config file (found in %SYSTEMROOT%\Microsoft.NET\Framework\vvvv\CONFIG). When an ASP.NET application is run, the properties from this file are read and overrides are applied in the application directories (to modify the machine.config file). Some of the parameters are thread-related and connection-related. This document references machine.config parameters; these files might require settings in addition to IIS 6.0 specific parameters.

Information about the ASP.NET configuration system inheritance can also be found at:

https://msdn.microsoft.com/library/en-us/cpguide/html/cpconconfigurationinheritance.asp.

Large Multiprocessor Servers

When consolidating important or mission-critical applications, it is not uncommon to use a large multi-processor server, as there is a greater capacity potential on that server and the hardware will also typically have additional reliability features built into it.

The Multiprocessor section (above) provides a detailed look at the performance, troubleshooting, and setup of large multiprocessor servers.