IIS 7.0 Performance - Adding Processing Power vs Load...

IIS 7.0 Performance: Adding Processing Power vs. Load BalancingWhite Paper

Published: February 2009

For the latest information, please visit www.iis.net.

http://www.iis.net/

ContentsOverview................................................................................................................................... 1

Benchmarking a Web Server................................................................................................1

Benchmarking IIS 7.0 – Various Scenarios...............................................................................3Test Scenario........................................................................................................................ 3Baseline Test........................................................................................................................ 3Using Web Capacity Analysis Tool (WCAT).........................................................................4Web Stress Test................................................................................................................... 7Test 1 – Scaling Up the Baseline Environment...................................................................14Test 2 – Scaling Out the Baseline Environment..................................................................19Notes and Assumptions......................................................................................................24

Conclusion.............................................................................................................................. 26

OverviewThis white paper illustrates two IIS 7.0 benchmarking scenarios and details the steps to monitor and fine-tune IIS 7.0 for improved performance and scalability. The following scenario is assumed: Web server administrators of a certain Web hosting company are preparing to launch a large-scale Windows-based hosting platform to handle the exceeding and diverse needs of their clients; the code for the Web application and Web site hosted on the new platform has already been or will be tested by the clients; and, performance and scalability statistics of the Web sites under IIS 7.0 in different loads has yet to be identified.

Three tests are described in this paper.

1. Baseline test: This provides the baseline architecture for further tests that demonstrate the performance of scaled environments. The baseline test gathers performance statistics on a baseline architecture comprised of a single 2.4 GHz machine with 8 GB RAM, which was exhausted when 600 requests/second were applied.

2. Test 1 – Adding Processing Power: The first scaling test is performed by scaling up the baseline architecture to a server machine with increased processing power (3 GHz processor) and memory (16 GB RAM). The processing resources of this environment were exhausted when approximately 6500 requests/second were applied.

3. Test 2 – Load Balancing: The second scaling test is performed by scaling out the baseline architecture on a distributed architecture having one machine with a 2.4 GHz processor and 8 GB RAM, and a second machine with 3 GHz processor and 16 GB RAM. The processing resources of this environment were exhausted when 40,000 requests/second were applied.

These tests will assist hosting administrators in locating performance and scalability bottlenecks within their hosting environments. By using the Microsoft Web Capacity Analysis Tool (WCAT) in a test environment to simulate the server load that can be expected in a production environment, the potential bottlenecks that may undermine the end user experience are pinpointed. Thoroughly studying this demonstration and applying different scenarios within their own environments will assist administrators in planning installation capacities and rectifying bottlenecks and other hardware level issues.

In hosting environments, the Web application or Web site code is normally the responsibility of the client, and IIS 7.0 takes every possible measure to isolate different Web applications where possible. This helps in identifying “bad” Web sites and Web applications and keeping them away from “good” Web sites.

This paper used WCAT to stress-test the site and gather performance and scalability metrics.

Benchmarking a Web ServerIn simple words, benchmarking a Web server is the process of gauging its ability to maintain a site's availability, reliability, and performance as the amount of simultaneous Web traffic, or load, hitting the Web server increases.

The two important factors that affect Web site scalability are performance and load management.

Performance

Performance refers to how efficiently a site responds to browser requests based on defined benchmarks. Performance of a certain application is affected by different complex factors, including application design and construction, database connectivity, network capacity and bandwidth, and hardware server resources such as processor, RAM, and storage. Application performance within a certain environment can be measured, designed, and tuned for optimal results.

Load Management

Load management is the method by which simultaneous user requests are distributed and balanced among multiple servers, such as Web, ColdFusion, DBMS, file, and search servers. Effectively balancing load across servers ensures the smooth and continuous availability of services to users.

Load management may be achieved through several different methods:

Hardware-based load management;

Software-based load management, including round-robin Internet DNS or third-party clustering packages;

Hardware and software combinations.

Benchmarking IIS 7.0 – Various ScenariosTest ScenarioTargeted for administrators of a large hosting company who are preparing to serve their hosting clients with a mix of static Web sites and dynamic ASP.NET applications, this paper assumes a single ASP.NET application called Time Management System (TMS), backed by an SQL Server 2005 database. TMS is a simple, online task management system application with:

68 static pages

9 C# code files

27 ASP.NET applications

Two tables in the database, each with a high number of records

Baseline TestThe test environment demonstrates how the ASP.NET Web application scales on a server with single 2 GHz processors running IIS 7.0. The goal is to stress the site to determine the number of requests per second that the deployment processed at, or nearly at, 100% CPU utilization. This section provides an analysis of how the site is expected to scale under a heavy load by understanding the application’s performance when the CPU is exhausted, and guides administrators in planning deployment capacity based on traffic estimates. This first test serves as a baseline for further tests that demonstrate the benchmarks in scaled architecture.

The following two tables describe the software and hardware used for the demonstration.

Table 1: Software SpecificationsType SpecificationOperating system Windows Server 2008

Web server Default installation of IIS 7.0

Language support ASP.NET (.NET framework 3.0)

Web application TMS – Time Management System

Database SQL Server 2005

Table 2: Hardware SpecificationsType SpecificationProcessor Dual 2.4-GHz Core 2 Duo Intel Pentium 4 Processors

RAM 4 GB

Router/Switch Netgear Wireless Router

Processor Four 3-GHz Intel Pentium 4 Processors

RAM 16 GB

Type SpecificationRouter/Switch 3COM 10/100

Using Web Capacity Analysis Tool (WCAT)Web Capacity Analysis Tool (WCAT) is a lightweight HTTP load generation tool primarily designed to measure the performance of a Web server within a controlled environment. WCAT can simulate thousands of concurrent users making requests to a single Web site or to multiple Web sites.

This section discusses the three main components of WCAT and their basic usage.

WCAT Client Management Utility – wcat.wsf

wcat.wsf is a utility script for managing a WCAT test environment. Table 3 lists the five main actions of this utility.

Table 3: WCAT Client Options# Name Switch Description1 Set clients -setclients Sets the default list of clients to use for test.

2 Terminate clients -terminateTerminates all instances of WCAT client on all client machines.

3 Update clients -updateUpdate WCAT client software and extension DLLs on all client machines; the first time forces the client to reboot.

4 Show clients -showclients Displays the list of clients to be used by wscat.wsf.

5 Run clients -runRuns WCAT client software on all client machines and then starts WCAT controller software locally.

WCAT Controller – wcctl.exe

The WCAT controller software is contained in a single binary, wcctl.exe, which coordinates the beginning and end of the test among all client machines. It also aggregates the data gathered from all clients into a single report and queries the Web server directly for performance counter data. Table 4 lists the five options of WCAT controller.

Table 4: Main Options Supported by WCAT Controller# Name Switch Description1 Client file -clientfile, -t The scenario file to use for the test to be run.

2 Settings file -settingsfile, -f The settings file to use.

3 Server -server, -sA comma-separated list of Web servers or IP addresses to generate load against; the list must contain no spaces (example: “web1,web2,web3” not “web1, web2, web3”).

4 Duration -duration, -u The duration in seconds that WCAT should run AFTER the warm-up phase; WCAT samples data during the duration

phase.

5Extended Information

-extended, -x

Specify this flag to enable extended information collection, including performance counters, registry value collection, and other miscellaneous server information, such as number of processors, CPU speed, total memory, etc.

WCAT uses two primary configuration files to describe how to generate load.

Settings File

The settings file describes the configuration specific to a particular test environment. Environment-specific settings are placed in the settings file, such as number of machines, number of virtual clients, Web server name, etc. The settings file is also referred to as the controller file because it is used primarily by the WCAT controller.

settings{ clientfile = “home.ubr”; server = “192.168.1.10”; clients = 2; virtualclients = 20; counters {…} registry {…}}

Sample Settings File

Scenario File

The scenario file is primarily utilized by the WCAT client process and is sometimes referred to as the client file. It describes the mix of URLs to request, how often to request them, the extension DLLs to load, etc.

scenario{ transaction { id = "foo"; weight = 1000; request { url = "/foo1.htm"; } request {

url = "/foo2.htm"; } } transaction { id = "bar"; weight = 2000; request { url = "/bar.htm"; } }}

Sample Scenario File

WCAT Client – wcclient.exe

wcclient.exe is the utility that serves as the client end of WCAT’s client–server architecture. wcclient.exe is copied to each physical client machine and is controlled through the WCAT controller. The basic function of WCAT client is to connect to the running WCAT controller and accept the testing parameters, such as number of virtual clients, server address, etc.

To run the WCAT client, wcclient.exe accepts the WCAT controller IP address as input.

WCAT Controller Waiting for Client Connections

WCAT Client Connected to the WCAT Controller

WCAT Demo Commands

The WCAT commands as used within the test, with slight modification of figures, are as follows.

Setting the client list

wcat.wsf -terminate –update –clients 192.168.1.1,192.168.1.2

Running WCAT controller

wcctl.exe -t home.ubr -f settings.ubr -x -l

This command signifies that all of the settings have already been saved in the scenario and settings file.

Batch files

To avoid typing the above commands repeatedly, creating one or more batch files for the easy execution of commands is recommended. To do this, open Notepad by clicking Start, then click Run, and type “Note” and press Enter.

Type any of the above commands into Notepad and save the file as filename.bat.

Double-click the newly created batch file to execute it. The new command window will launch and display the execution of commands until the process completes, and will close automatically upon completion. The batch file can be run from within the command window by simply browsing through the directory of batch files and typing its name.

WCAT Controller Batch File

Nine Steps to Running WCAT

1. Start the Web server.

2. Prepare the controller input files.

3. Start the WCAT controller.

4. Start the WCAT clients.

5. The warm-up period.

6. The test period.

7. The cool-down period.

8. The reporting period.

9. Prepare the output files.

Web Stress TestThe following section discusses WCAT settings and the process of exhausting Web server resources.

Test Preparation

The WCAT configuration file was set up to run 90 virtual users on three physical client machines (each running 30 threads). The WCAT distribution file was set up to imitate real-world use of the Web application. Table 5 shows the breakdown of the WCAT distribution file based on the assumptions.

Table 5: WCAT Distribution File DescriptionRequest #

Percentage of Requests

Request Description

1 50 Users browse the tasks list. The highest percentage of requests is assigned to this action based on the expectation of the highest percentage of real-world traffic to the Web application.

2 30 User uses the pagination option to browse through records beyond the first page. These requests are assumed to have the second highest share among the total requests and have a different level of impact on the server because of different database queries.

3 20 User searches for a task. These requests are relatively low in number but put more stress on the server by searching within a large number of records.

Test Configuration Files

WCAT settings file

Based on the environment, the required variables in the settings file were set as follows:

Name of the “scenario file” to be used

clientfile = "home.ubr"; IP address of the server to be tested

server = "192.168.1.10"; Number of physical machines

clients = 3; Number of virtual users per physical machine totaling 90 virtual users

virtualclients = 30;

Interval defined within the counter{..} section to set the interval at which the WCAT controller polls the results from WCAT clients

interval = 10 Processor activity counter to be logged

counter = "Processor(_Total)\\% Processor Time";

WCAT scenario file

Based on the environment, the require variables in the scenario file were set as follows:

Warm up duration during which WCAT sends but does not log the requests

warmup = 180 Duration of test

duration = 360 Cool-down duration

cooldown = 60 Three transaction variables set as follows

Transaction 1 Transaction unique ID

id = "helloworld"

Transaction priority to signify the frequency that this request is made compared with other requestsweight = 100


id = "helloworld1"



id = "helloworld2"


Common variables with the same values for all three transactions

Authentication type with appropriate credentialsauthentication = NTLMusername = "Administrator"password = "xxxxxxxx"

Emulating User Load to the Web Site

The following image illustrates the test environment’s network diagram, which comprises:

One Windows Server 2008 with IIS 7.0 and SQL Server 2005;

One WCAT controller server running on a Windows 2003 machine;

Three WCAT client machines running Windows XP and each configured to simulate the load of 30 users.

Test 1 Network Diagram

Duration

The first test was run for 10 minutes. This was a sufficient length of time because the test was intended only to identify the bottlenecks and performance issues in the server software, not in the hardware, and was also not intended to detect bugs or issues with the Web application.

Network Status

During the test, the network was monitored continuously to ensure that the connection, with a capacity of 1 GB, was not saturated. On the Networking tab in Windows Task Manager, network traffic remained steady at 7% and sometimes moved even slower, proving that the network was not a bottleneck.

Processor Status

We then opened System Monitor and monitored the Processor(_Total)\% Processor Time counter. The counter showed that the CPU was saturated at 100%. The graph shows a steady horizontal line at the top vertical limit of processor usage percentage.

The test was run several more times with fewer virtual users, at 35, 45, 55, 65, and 75. The CPU did not always reach 100% saturation, and dropped from the top mark significantly. We found that 90 virtual users was the exact mark at which the CPU reached 100% utilization. Anything below this did not allow the CPU to reach the 100% mark; similarly, anything above this was irrelevant.

The test concluded that the data reflecting a run of 90 virtual users suited capacity planning needs.

Since the test was run in an isolated environment to obtain the appropriate results, the WCAT logs revealed no errors. This led to the conclusion that the bottleneck was the CPU. The server installation could not scale beyond the 90 virtual users because the server did not have sufficient processing power.

Processor Usage with Virtual Users Less Than 90

Processor Usage Rose to 100% Utilization with 90 Virtual Users

Processor Usage Down to Nearly 0% at the End of the Test

Other Performance Counters

If the initial attempt to saturate the CPU had failed, that would have indicated that the bottleneck was elsewhere in the installation, such as at disk I/O or database activity. In the test case, the disk I/O graph remained at an acceptable level.

Also, a badly written application can be the source of a bottleneck in cases in which the CPU is not saturated during stress testing. A badly written application normally adversely affects the three performance counters—processor, memory, and disk I/O. However, IIS 7.0 architecture executes code in such a way that the possibility that one bad application will affect other applications within the same environment is nearly eliminated.

Analysis of the Test

Table 6: Web Stress Test AnalysisCalculation Equation ResultWCAT requests per second From WCAT logs 596

Processor megacycles per second 2 2458 (Dual 2.4 GHz) 4,916

Processor cycles per second 4916 1000 1000 4,916,000,000

Processor cycles per request 4916000000/596 8,248,322 (~8.3 million)

Requests per day Assuming 10 million 10,000,000

Requests per second 10000000/60/60/24 116 (~120)

Processor utilization per second 8.3 MHz 120 996 MHz

Average processor utilization percentage (996/4916) 100 20%

Test Reports

This section contains snippets of reports generated by WCAT.

NoteThe requests per day figure assumed above specifically means, “Let’s suppose the Web server is expecting five million requests per day. Calculate whether it can handle this number of requests. If it can, then what would processor utilization be?”We calculated the throughput of the server at 100% utilization but a server should not run at 100% utilization all the time. Therefore, the calculation of server throughput at certain acceptable processor utilizations, such as 30%, is required.

Test Report Summary

Processor Utilization Summary (Partial)

Conclusion of the Test

The calculation within the analysis section shows that the current server deployment for the Web application can handle 10 million requests per day without exceeding 25% CPU utilization at any given time of day.

The 10 million figure was initially assumed in the calculation of server throughput at certain acceptable processor utilization levels, i.e., from 15% to 40%. Therefore, this deployment of hosting servers can easily support any hosting environment and between 10 million to 13 million requests per day, or 600 to 625 requests per second.

Test 1 – Scaling Up the Baseline EnvironmentThis section discusses the outputs of the tests done after deploying the application on a server machine with nearly four times the processing speed of the first machine installed on the standard server motherboard.

Definition

Scaling up means increasing the processing capabilities of a server by adding hardware units such as processors, RAM, and faster I/O disks. This is normally done to increase the number of sites and Web applications that a server can host or to enable the Web server to support a higher number of requests.

Benefits

Scaling up is an inexpensive way to boost performance, especially if the majority—if not all—of the Web sites hosted on a server contains static content.

Test Preparation

This time, we set up the WCAT configuration file to run 1200 virtual users on four physical client machines, each running 300 threads. The WCAT distribution file was set up to imitate real-world use of the Web application.

Test hardware

Server machine with:

Quad 3 GHz Pentium 4 Processors

16 GB RAM

Four client machines with:

1.3 GHz Pentium 4 Processors

1 GB RAM

Test configuration files

For the second test, the Web application along with the database was transferred from the server utilized in the first test to the new server, which had increased processing power and memory.

After migrating the application, the WCAT stress test was performed with the following configuration.

Based on the environment, the required variables in the WCAT settings file were set as follows:

Name of the “scenario file” to be used



clients = 4; Number of virtual users per physical machine, for a total of 1200 virtual users

virtualclients = 300; Interval defined within the counter{..} section to set the interval at which WCAT controller

will poll the results from WCAT clients

interval = 10 Processor activity counter to be logged

counter = "Processor(_Total)\\% Processor Time";

Based on the environment, the required variables in the WCAT scenario file was set as follows:

Warm up duration during which WCAT sends but does not log the requests

warmup = 180 Duration of test

duration = 360 Cool down duration

cooldown = 60 Three transactions set as follows

Transaction 1Transaction unique ID

id = "helloworld"

Priority of the transaction to signify the frequency at which this request is made compared with other requests

weight = 100


id = "helloworld1"


weight = 60


id = "helloworld2"


weight = 30

Common variables with the same values for all three transactions

Authentication type with appropriate credentials

authentication = NTLMusername = "Administrator"password = "xxxxxxxx"


The following figure shows the network diagram of the test environment, which comprises:

One Windows Server 2008 with IIS 7.0 and SQL Server 2005;


Four WCAT client machines running Windows XP and each configured to simulate the load of 300 users.


The Test

The test was started by simulating the load of double the number of virtual users of the first test, or 180 (90 2). Then, to raise the CPU utilization to 100%, several tests were performed using 360, 700, 1000, 1100, and 1200 virtual users. CPU utilization rose to a constant 100 percent with a load of 1200 users.

The network status of the client machines was checked from the Task Manager, and was at an acceptable level, fluctuating at around 7%. The network status on the server machine showed that the network hovered around 19%. Since the server’s processing power was successfully exhausted, the processor was once again the bottleneck. However, this time the server was able to handle many more requests per second than the previous server configuration.

Table 7: Scaling Up Test AnalysisCalculation Equation ResultWCAT requests per second From WCAT logs 6307

Processor megacycles per second 4 3072 (Four 3 GHz) 12,288

Processor cycles per second 12288 1000 1000 12,288,000,000

Processor cycles per request 12288000000/6307 1,948,311 (~2 million)

Requests per day Assuming 75 million 75,000,000

Requests per second 60000000/60/60/24 868 (~870)

Processor utilization per second 2 MHz 870 1740 MHz

Average processor utilization percentage (1740/12288) 100 15%

Test Reports

This section contains snippets of reports generated by WCAT.

Test Report Summary

Processor Utilization Summary (Partial)

Scaling Up Conclusion

Calculations in the “Analysis Section” show the following:

The server with two 2.4 GHz processors and 4 GB RAM performed 596 requests/second;

The server with four 3 GHz processors and 16 GB RAM performed 6307 requests/second.

When moving from a single 2 GHz processor to four 3 GHz processors, the test deployment scaled at a ratio of:

[(6307/12288) / (596/4916)] 100 = 1 to 4.2

The above test for scaling up the hosting environment shows that increasing the sever hardware configuration in a certain ratio does not necessarily increase the throughput in the same ratio. Yet, the scaling up scenario produces relatively better results.

The dramatic increase in server throughput was observed because of an increase in all major hardware configurations:

Nearly a four times increase in processing power;

A four times increase in available memory;

Use of RAID drives instead of SCSI drives.

The increase in available memory actually enabled the server to cache more information than the previous server.

Test 2 – Scaling Out the Baseline EnvironmentThis section discusses the outputs of tests done after deploying the application on two servers with different processing speeds set up in a load-balancing environment.

Definition

Scaling out is the process of adding servers to an existing server environment to improve performance and increase the throughput of the hosting environment, either by serving a higher number of requests per second or by hosting more Web sites.

Benefits

Scaling out requires relatively more time, effort, and money. However, it reduces bottlenecks and lock contention because requests coming into the hosting environment do not share resources. The request load is balanced among servers through load balancing mechanisms.

Test Preparation

In the third testing scenario, two Web servers were configured to run in a load-balancing environment using the Windows Server 2008 load-balancing feature called NLB (Network Load Balancer).

In the setup in which Web servers run in cluster mode, the WCAT configuration file was set up to run 12,000 virtual users on 20 physical client machines, each running 600 threads. The massive number of virtual users is intended to ensure that sufficient load is applied on the clustered servers.

Test hardware

One server machine (NLB primary node):

Quad 3 GHz Pentium 4 Processors

16 GB RAM

Two network interfaces installed

One server machine (NLB secondary node):

Quad 2.4 GHz Pentium 4 Processors

8 GB RAM

Twenty client machines:

1.4, 1.7 and 2.4 GHz Pentium 4 Processors

1 GB RAM

Test configuration files

In the cluster environment, the Web application and the complete database was copied and configured on both server machines. The WCAT settings file was edited to produce the desired traffic.

Based on the environment, the required variables in the WCAT settings file were set as follows:

Name of the scenario file to be used



clients = 20; Number of virtual users per physical machine, totaling 1200 virtual users

virtualclients = 600;


The following figure shows the network diagram of the test environment, which comprises:

One server with Windows Server 2008, IIS 7.0, SQL Server 2005, and the NLB feature installed;

One server with Windows Server 2008, IIS 7.0, SQL Server 2005, and the NLB feature installed and configured as the primary node of the NLB cluster;


Twenty WCAT client machines running Windows XP, each configured to simulate the load of 600 users.


Using Network Load Balancer (NLB)

Network Load Balancing (NLB) is available in all variants of Windows Server 2008. Essentially, NLB uses a node-based distributed process that farms network traffic between a number of hosts or nodes, where each node constitutes a member of an NLB cluster.

NLB is different from the Windows Failover Clustering Services. NLB clustering is designed mainly around the distribution of network traffic and provides fault tolerance at the interface level.

To install and correctly configure NLB in our test environment, we conducted the following steps:

Used three different IP addresses for the cluster-specific configuration;

Assigned the first IP address on one network interface of the machine intended for use as the primary node. The Web application is browsed through this IP address or, in other words, it is the cluster IP address;

Assigned the second IP address on the second network interface of the primary node;

Assigned the third IP address on the single available network interface of the machine intended for use as the secondary node;

Installed the NLB feature on both servers (cmd -> serverManagerCMD -i NLB);

Created a new cluster on the primary node using Network Load Balancing Manager (START -> Programs -> Administrative Tools -> Network Load Balancing Manager);

Set up the first node (the machine itself) and configured the cluster IP address as assigned on the first network interface;

Set up the port rules to allow port 80 (HTTP) and port 443 (HTTPS);

Once configured, added the second server to the cluster (main screen of NLB cluster -> right-click on the newly created cluster name under Network Load Balancing Clusters -> click on Add Host to Cluster);

Completed the two-step configuration of the second server and clicked on Finish;

Browsed the application through the cluster IP address returned on the appropriate page.

The following are a few screenshots from the above process.

NLB installation

Network Load Balancing Manager Shortcut

New Cluster from Network Load Balancing Manager

Primary Cluster Node

Primary Node’s Priority

Cluster Ports Configuration

The Test

After installing and configuring Network Load Balancing on the two servers—one with four 2.4 GHz processors / 8 GB RAM and one with four 3 GHz processors / 16 GB RAM—the WCAT stress test was run using 12,000 virtual users—twenty client computers running 600 threads each.

After the test was completed, as one Network Load Balancing node, the two servers served approximately 40,000 requests per second when the Processor (_Total)\% Processor Time counter reached 100%.

Table 8: Scaling Out Test AnalysisServer Configuration

Megacycles / Second

Requests / Second

Megacycles / Request

4 2.4 GHz 4916 596 8.24

4 3 GHz 12288 6307 1.94

4 2.4 GHz+

4 3 GHz

22,118 40,000 0.55

Scaling Out Conclusion

The megacycles per request matrix shown in the test analysis section above signifies a roughly 15% increase in overall throughput and added reliability. This is because, in the Network Load Balancing test, the number of requests per second increased and the megacycles per request reduced significantly.

Notes and AssumptionsThe following considerations and assumptions were made before and during the execution of the above tests, which may differ from the production hosting environment.

Each test was run several times to determine the exact point at which CPU utilization reached 100%.

Only a single application with dummy data of one million records per table was used to perform all of the tests.

The Web application response time is not discussed in great detail but was shown in the snippets of reports produced by WCAT.

Realistically, overhead created by system resources and issues such as lock contention did not allow a system to scale linearly; therefore, a scale ratio of 1 to 4 should not be expected when moving from one to four processors.

The tests were run in a completely isolated network, eliminating any unforeseen problems.

The assumptions for requests per second made in the analysis section of the first two tests were made to actually calculate and determine how the deployment will perform when administrators expect a certain number of records per day.

The Web server (IIS 7.0) and database server (SQL Server 2005) were running on the same server machine.

Conclusion

With the significant 70% reduction in required megacycles/request from baseline configuration to distributed architecture, the number of requests that an environment was able to handle increased from 600/sec to 40,000/sec. This significant increase in throughput shows that the distributed architecture resulted in nearly 40 times better performance. Keeping the assumptions and considerations in view, the results have an accuracy of 97% for this specific environment.

Megacycles/request in baseline configuration: 8.24

Megacycles/request in distributed architecture: 0.55

Reduction in megacycles/request: 70%

Requests/second in baseline configuration: ~600

Requests/second in distributed architecture: 40,000

The demonstration of different tests displayed the great capabilities of IIS 7.0. The Microsoft Web server family has produced the finest of its kind with the development and release of the new robust, scalable, and secure architecture of IIS 7.0.

The isolated and secure architecture of IIS 7.0 provided with the scalability feature of Windows Server 2008 enabled the server to effectively handle the massive number of requests per second.

After performing different tests and reaching up to the distributed environment with multiple servers, the last benchmark for Web server performance is reflected by the applications hosted by a server. After reaching the maximum throughput of the environment without any errors, the applications remain as the only piece to be tested and optimized. IIS 7.0 has made life easier for administrators in this domain as well. It provides isolated execution of work processes and an enhanced level of application pools. The extensive logging capabilities of IIS 7.0 enable administrators to actually pinpoint faulty applications.

With the completion of all of the above tests, it is clear that a server with an optimal configuration, especially in load balancing architecture and running IIS 7.0, can easily handle millions of records per day without exceeding the standard processor utilization peak of 25%. Deploying the database server on a different machine can reduce this utilization peak even more significantly.

This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in, or introduced into a retrieval system, or transmitted in any form or by any means (electronic,

mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2009 Microsoft Corporation. All rights reserved.

IIS 7.0 Performance - Adding Processing Power vs Load...

Documents

Transcript of IIS 7.0 Performance - Adding Processing Power vs Load...