IIS 7.0 Performance: Adding Processing Power
vs. Load Balancing
White Paper
Published: February 2009
For the latest information, please visit www.iis.net.
Contents
Overview .....................................................................................................................................1
Benchmarking a Web Server ..................................................................................................2
Benchmarking IIS 7.0 – Various Scenarios ..................................................................................3
Test Scenario ..........................................................................................................................3
Baseline Test...........................................................................................................................3
Using Web Capacity Analysis Tool (WCAT) ............................................................................4
Web Stress Test ......................................................................................................................8
Test 1 – Scaling Up the Baseline Environment .................................................................... 15
Test 2 – Scaling Out the Baseline Environment .................................................................. 20
Notes and Assumptions....................................................................................................... 26
Conclusion ............................................................................................................................... 27
Overview
This 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.
IIS 7.0: Adding Processing Power vs. Load Balancing
1
Benchmarking a Web Server
In 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.
IIS 7.0: Adding Processing Power vs. Load Balancing
2
Benchmarking IIS 7.0 – Various Scenarios
Test Scenario
Targeted 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 Test
The 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 Specifications
Type
Specification
Operating 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 Specifications
Type
Specification
Processor
Dual 2.4-GHz Core 2 Duo Intel Pentium 4 Processors
RAM
4 GB
IIS 7.0: Adding Processing Power vs. Load Balancing
3
Type
Specification
Router/Switch
Netgear Wireless Router
Processor
Four 3-GHz Intel Pentium 4 Processors
RAM
16 GB
Router/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
Description
1
Set clients
-setclients
Sets the default list of clients to use for test.
2
Terminate clients
-terminate
Terminates all instances of WCAT client on all client
machines.
3
Update clients
-update
Update 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
-run
Runs 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
Description
1
Client file
-clientfile, -t
The scenario file to use for the test to be run.
IIS 7.0: Adding Processing Power vs. Load Balancing
4
2
Settings file
-settingsfile, -f
The settings file to use.
3
Server
-server, -s
A 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 warmup phase; WCAT samples data during the duration phase.
5
Extended
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";
IIS 7.0: Adding Processing Power vs. Load Balancing
5
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.
IIS 7.0: Adding Processing Power vs. Load Balancing
6
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.
IIS 7.0: Adding Processing Power vs. Load Balancing
7
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 Test
The 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 realworld use of the Web application. Table 5 shows the breakdown of the WCAT distribution
file based on the assumptions.
Table 5: WCAT Distribution File Description
Request #
Percentage of Request Description
Requests
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";
IIS 7.0: Adding Processing Power vs. Load Balancing
8

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 requests
weight = 100
Transaction 2
 Transaction unique ID
id = "helloworld1"
 Transaction priority to signify the frequency that this request is made compared
with other requests
weight = 60
Transaction 3
 Transaction unique ID
id = "helloworld2"
 Transaction priority to signify the frequency that this request is made compared
with other requests
weight = 30
IIS 7.0: Adding Processing Power vs. Load Balancing
9

Common variables with the same values for all three transactions
Authentication type with appropriate credentials
authentication = NTLM
username = "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.
IIS 7.0: Adding Processing Power vs. Load Balancing
10
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
IIS 7.0: Adding Processing Power vs. Load Balancing
11
Processor Usage Rose to 100% Utilization with 90 Virtual Users
Processor Usage Down to Nearly 0% at the End of the Test
IIS 7.0: Adding Processing Power vs. Load Balancing
12
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 Analysis
Calculation
Equation
Result
WCAT 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%
Note
The 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 Reports
This section contains snippets of reports generated by WCAT.
IIS 7.0: Adding Processing Power vs. Load Balancing
13
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
IIS 7.0: Adding Processing Power vs. Load Balancing
14
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 Environment
This 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:
IIS 7.0: Adding Processing Power vs. Load Balancing
15

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 = 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 1
Transaction unique ID
id = "helloworld"

Priority of the transaction to signify the frequency at which this request is made
compared with other requests
weight = 100
Transaction 2
Transaction unique ID
id = "helloworld1"

Priority of the transaction to signify the frequency at which this request is made
compared with other requests
weight = 60
Transaction 3
IIS 7.0: Adding Processing Power vs. Load Balancing
16
Transaction unique ID
id = "helloworld2"

Priority of the transaction to signify the frequency at which this request is made
compared with other requests
weight = 30

Common variables with the same values for all three transactions
Authentication type with appropriate credentials
authentication = NTLM
username = "Administrator"
password = "xxxxxxxx"
Emulating User Load to the Web Site
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;

One WCAT controller server running on a Windows 2003 machine;

Four WCAT client machines running Windows XP and each configured to simulate the
load of 300 users.
Test 2 Network Diagram
IIS 7.0: Adding Processing Power vs. Load Balancing
17
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 Analysis
Calculation
Equation
Result
WCAT 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%
IIS 7.0: Adding Processing Power vs. Load Balancing
18
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:
IIS 7.0: Adding Processing Power vs. Load Balancing
19

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 Environment
This 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
IIS 7.0: Adding Processing Power vs. Load Balancing
20
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
clientfile = "home.ubr";

IP address of the server to be tested
server = "192.168.1.10";

Number of physical machines
clients = 20;

Number of virtual users per physical machine, totaling 1200 virtual users
virtualclients = 600;
Emulating User Load to the Web Site
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;

One WCAT controller server running on a Windows 2003 machine;
IIS 7.0: Adding Processing Power vs. Load Balancing
21

Twenty WCAT client machines running Windows XP, each configured to simulate the
load of 600 users.
Test 3 Network Diagram
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;
IIS 7.0: Adding Processing Power vs. Load Balancing
22

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
IIS 7.0: Adding Processing Power vs. Load Balancing
23
Network Load Balancing Manager Shortcut
New Cluster from Network Load Balancing Manager
Primary Cluster Node
Primary Node’s Priority
IIS 7.0: Adding Processing Power vs. Load Balancing
24
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 Analysis
Server 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
22,118
40,000
0.55
+
4  3 GHz
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.
IIS 7.0: Adding Processing Power vs. Load Balancing
25
Notes and Assumptions
The 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.
IIS 7.0: Adding Processing Power vs. Load Balancing
26
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.
IIS 7.0: Adding Processing Power vs. Load Balancing
27
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: Adding Processing Power vs. Load Balancing
28