IIS 7.0 Performance: Adding Processing Power vs. Load Balancing

yompmulligrubsInternet και Εφαρμογές Web

31 Οκτ 2013 (πριν από 3 χρόνια και 7 μήνες)

89 εμφανίσεις






IIS

7.0

Performance
: Adding Processing
P
ower
vs. Load Balancing

White Paper

Published:
February 2009

For the latest information, please
visit

www.iis.net
.




1



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

................................
...............................

16

Test 2


Scaling Out the Baseline Environment

................................
..............................

21

Notes and Assumptions

................................
................................
...............................

28

Conclusion

................................
................................
................................
......................

29






IIS 7.0: Adding Processing Power vs. Load Balancing

1


Overview

This
white
paper illustrates
two
IIS 7.0 benchmarking

scenarios and
details the steps
to
monitor and fine
-
tun
e

IIS 7.0 for improved performance and scalability.
The following
scenario is
assume
d
:
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
W
eb application and
Web site
hosted on
the new platform
has
already been
or will be

t
ested by the clients
; and, p
erformance and
scalability statistics of
the
Web sites
under
IIS
7.0

in
different loads
has
yet to be identified.

T
hree tests are
described
in this paper.

1.

Baseline
test
:
T
his
provides the
baseline
architecture
for further tests
that
demonstr
ate

the performance of scaled environments. The baseline test
gather
s

performanc
e
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 resource
s

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 environmen
t
were
exhausted when 40
,
000 requests/second
were
applied.

T
hese
tests

w
ill

assist
hosting administrators
in
locat
ing

performance and scalability
bottlenecks
with
in their hosting
environment
s
. 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 s
tudying this demonstration and applying different
scenario
s within their own environment
s will assist
administrators
in
plan
ning

installation
capacit
ies

and rectify
ing

bottlenecks and other hardware level issues.

In hosting environments, the
Web
application or
Web
site code is normally the responsibility
of the c
lient, 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
.

T
his paper used
WCAT

to stress
-
test the site
and gather performance and scalability metrics
.



IIS 7.0: Adding Processing Power vs. Load Balancing

2


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 tra
ffic
,
or load
,
hitting the Web
server increases.

The two important factors th
at 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, a
nd 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
service
s

to users
.

L
oad 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

3


Benchmarking
IIS 7.0


Various Scenarios

Test Scenario

Targeted
for
administrators of a large hosting c
ompany 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 provid
es 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 serve
s

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

Wi ndows
Server


2008

Web server

Default installation of IIS 7.0

Language support

ASP.NET (.NET framework 3.0)

Web application

TMS


Ti me
M
anagement
S
ystem

Database

SQL Server


2005




IIS 7.0: Adding Processing Power vs. Load Balancing

4


Table
2
: Hardware Specifications

Type

Specification

Processor

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

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

w
cat
.wsf is a utility script for managing a WCAT test environment.
Table 3 lists t
he
five main
actions of t
his utility.

Table
3
: WCAT Client Options

#

Name

Switch

Description

1

Set cl i ents

-
setclients

Sets the default list of cl ients to use for test
.

2

Termi nate cl ients

-
termi nate

Termi nate
s

all i nstances of WCAT cl ient on all client
machines
.

3

Update
clients

-
update

Update WCAT cl ient software and extension DLLs on all
cl i ent machines; the first ti me forces the client to reboot
.

4

Show cl ients

-
showclients

Di splay
s

the list of cl ients to be used by wscat.wsf
.

5

Run cl ients

-
run

Run
s

WCAT cl ient software on all cl ient machines and then
start
s

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


IIS 7.0: Adding Processing Power vs. Load Balancing

5


gathered from all clients into a single report and queries the Web server directly for
performance counter data.

Table 4 lists t
he five
options

of
WCAT controller
.

Table
4
: Main Options Supported by WCAT
Controller

#

Name

Switch

Description

1

Cl i ent file

-
cl i entfile,
-
t

The scenario file to use for the test to be run
.

2

Setti ngs 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 warm
-
up phase; WCAT samples data during the duration phase
.

5

Exte
nded
Information

-
extended,
-
x

Speci fy this flag to enable extended i nformation collection,
i ncl uding performance counters, registry value collection, and
other mi scellaneous server i nformation, 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
s
ettings file describes the configuration specific to a particular test environment.
Environment
-
specific settings are placed in the
s
ettings file, such as numbe
r of machines,
number of virtual clients, Web server

name
, etc. The
s
ettings file is also referred to as the
controller file because it is used primarily by the WCAT controller.


settings

{


cl i entfile =
“home.ubr”;


server =
“192.168.1.1
0”;


cl i ents =
2
;


vi rtualclients =
20
;




counters {…}


regi stry {…}

}

Sample Settings File



IIS 7.0: Adding Processing Power vs. Load Balancing

6


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


{



i d = "foo";


wei ght = 1000;


request


{


url = "/foo1.htm";


}


request


{


url = "/foo2.htm";


}


}


transaction


{


i d = "bar";


wei ght = 2000;


reque
st


{


url = "/bar.htm";


}


}

}

Sample Scenario File

WCAT Client


wcclient.exe

w
cclient.exe is the utility that serves as the client end of WCAT’s client

server architecture.
w
cclient.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, e
tc.

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



IIS 7.0: Adding Processing Power vs. Load Balancing

7



WCAT Controller
W
aiting for
C
lient
C
onnections


WCAT
C
lient
C
onnected
to the WCAT
C
ontroller

WCAT Demo Commands

The WCAT commands as used within the test
,

with sli
ght 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
.



IIS 7.0: Adding Processing Power vs. Load Balancing

8


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 pro
cess 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
C
ontroller
B
atch
F
ile

Nine Steps to Running WCAT

1.

Start the Web server
.

2.

Prepar
e

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.

Prepar
e

the output files
.

Web Stress Test

The following section di
scusses WCAT settings and the process of exhausting Web server
resources.

Test Preparation

T
he 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.



IIS 7.0: Adding Processing Power vs. Load Balancing

9


Table
5
: WCAT Distribution File Description

Request

#

Percentage of
Requests

Request Description

1

50

Users browse the tasks

l ist. 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
fi rst page. These requests are assumed to have the second
highest
share
among the total requests and have a different l evel of impact on the
server because of different database queries.

3

20

User searches for a task. These requests are relatively l ow i n 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, t
he
required variables in t
he
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, t
he
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



IIS 7.0: Adding Processing Power vs. Load Balancing

10




Duration of test

duration = 360



Coo
l
-
down duration

cooldown = 60



Three transaction

variable
s set as follows

Transaction 1



Transaction unique ID

id = "helloworld"



T
ransaction
p
riority
to signify the frequency that this request is made compared
with other requests

weight = 100

Transaction 2



Transaction unique ID

id = "helloworld1"



Transaction p
riority
to signify the frequency that this request is made compared
with other requests

weight = 60

Transaction 3



Transaction unique ID

id = "helloworld2"



Transaction p
riority
to signify the frequency t
hat 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"

Emula
ting
U
ser
L
oad
to the Web
S
ite

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
c
ontroller
s
erver
running on a Windows


2003 machine
;



Three WCAT
client machines running Windows


XP and each configured to simulate the
load of 30 users
.



IIS 7.0: Adding Processing Power vs. Load Balancing

11



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 bottl
enecks 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
en
sure that the connection,
wi
th 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 a
nd 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 f
ewer virtual users
, at
35, 45, 55, 65, and 75
.
T
he
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 n
ot 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
ap
propriate results, the
WCAT logs revealed no errors
. This led to the
conclu
sion

that the bottleneck
was
the CPU.


IIS 7.0: Adding Processing Power vs. Load Balancing

12


The server installation could not scale beyond the 90 virtual users because the server did not
have sufficient processing power.


Processor
U
sage
with
V
irtual
U
sers
L
ess
T
han
90




IIS 7.0: Adding Processing Power vs. Load Balancing

13


Processor
U
sage
R
ose
to 100%
U
tilization
with 90
V
irtual
U
sers


Processor
U
sage
D
own
to
N
early
0% at the
E
nd
of the
T
est

Other Performance Counters

If the initial attempt to saturate the CPU had failed,
that would ha
ve 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.



IIS 7.0: Adding Processing Power vs. Load Balancing

14


Analysis of the
Test

Table
6
: Web Stress Test Analysis

Calculation

Equation

Result

WCAT requests per second

From WCAT l ogs

596

Processor megacycl es
per second

2



2458 (Dual 2.4 GHz)

4,916

Processor cycl es per second

4916


1000


1000

4,916,000,000

Processor cycl es per request

4916000000/596

8,248,322 (~8.3 mi l lion)

Requests per day

Assuming 10 mi llion

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.


Note

The requests per day figure assumed above specifically means, “Let’s
suppose the Web server is
expecting five million requests per day
.

C
alculate 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.



IIS 7.0: Adding Processing Power vs. Load Balancing

15



Test
R
eport
S
ummary


Processor
U
t
ilization
S
ummary
(
P
artial
)

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
calculat
ion 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

16


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 no
rmally 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 al
l

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.



IIS 7.0: Adding Processing Power vs. Load Balancing

17


Bas
ed on
the environment
,

t
he
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

= 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



P
rocessor 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

w
armup

= 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"



IIS 7.0: Adding Processing Power vs. Load Balancing

18




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

weight = 60

Transaction 3

Transaction unique ID

id = "h
elloworld2"



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 transaction
s

Authentication type with appropriate credentials

authentication = NTLM

username = "Administrator"

password = "xxxxxxxx"

Emulating
U
ser
L
oad
to the Web
S
ite

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
.



IIS 7.0: Adding Processing Power vs. Load Balancing

19



Test 2 Network Diagram

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 user
s.

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 pow
er
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.



IIS 7.0: Adding Processing Power vs. Load Balancing

20


Table
7
: Scaling Up Test Analysis

Calculation

Equation

Result

WCAT requests per second

From WCAT l ogs

6307

Processor megacycl es per second

4


3072 (Four 3 GHz)

12,288

Processor cycl es per second

12288


1000


1000

12,288,000,000

Processor cycl es per request

12288000000/6307

1,948,311 (~2 mi l lion)

Requests per

day

Assuming 75 mi llion

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



IIS 7.0: Adding Processing Power vs. Load Balancing

21



Processor Utilization Summary (
P
artial)

Scaling Up Conclusion

Calculations in the “Analysis Section” show the following:



The server
with two 2.4

GHz processor
s

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 i
ncrease in server throughput was observed because of an increase in all major
hardware configurations:



Nearly a four times increase in processing power;



A f
our times increase in available memory;



Use of
RAID
drives instead of SCSI drives.

The increase in a
vailable 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 pro
cessing speeds set up in a load
-
balancing environment.



IIS 7.0: Adding Processing Power vs. Load Balancing

22


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 numbe
r 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. T
he 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 intende
d to ensure that sufficient load is applied on the
clustered servers.

Test hardware

One
s
erver
machine (NLB primary node):



Quad 3 GHz Pentium 4 Processors



16 GB RAM



Two network
i
nterfaces
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



IIS 7.0: Adding Processing Power vs. Load Balancing

23


Test configuration files

In the cluster environment, the Web application
and

the complete database was copied and
configured on both serv
er machines. The WCAT settings file was edited to produce the
desired traffic.

Based on
the environment
,

t
he
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 s
erver 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
U
ser
L
oad
to the Web
S
ite

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
c
ontroller
s
erver
running on a Windows


2003 machine;



Twenty WCAT client machines running Windows


XP
,

each configured to simulate the
load of 600 users.



IIS 7.0: Adding Processing Power vs. Load Balancing

24




Test 3 Network Diagram

Using Network Load Balance
r (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 e
nvironment, 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 brows
ed through t
his
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);



IIS 7.0: Adding Processing Power vs. Load Balancing

25




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 clust
er (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

26


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

27




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

t
he 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 /
S
econd

Requests /
S
econd

Megacycles /
R
equest

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


IIS 7.0: Adding Processing Power vs. Load Balancing

28


Network Load Balancing test, the number of requests per second increased
and
the
megacycles per request reduced
significantly
.

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
reach
ed 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.



Realisti
cally, 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 i
solated 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 cer
tain number of records per day.



The
Web server (IIS 7.0) and
d
atabase
server (SQL Server


2005) were running on the
same server machine.



IIS 7.0: Adding Processing Power vs. Load Balancing

29


Conclusion


With the significant 70% reduction
in
required
megacycles
/request from baseline
configuration to distribute
d 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
provid
es

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%.
D
eploying the database server
on a different machine

can reduce this utilization peak
even more significantly
.



IIS 7.0: Adding Processing Power vs. Load Balancing

30




This is a preliminary document and may be changed substantially prior to f inal commercial release of the sof tware described h
erein.

The inf ormation contained in this
document represents the current v iew of Microsof t Corporation on the issues discussed as of the
date of publication. Because Microsof t must respond to changing market conditions, it should not be interpreted to be a commi
tment
on the part of Microsof t, and

Microsof t cannot guarantee the accuracy of any inf ormation presented af ter the date of publication.

This white paper is f or inf ormational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS
DOCUMENT.

Comply ing with all applicable cop
y right laws is the responsibility of the user. Without limiting the rights under copy right, no part of this
document may be reproduced, stored in, or introduced into a retriev al sy stem, or transmitted in any f orm or by any means (ele
ctronic,
mechanical, ph
otocopy ing, recording, or otherwise), or f or any purpose, without the express written permission of Microsof t
Corporation.

Microsof t may hav e patents, patent applications, trademarks, copy rights, or other intellectual property rights cov ering subje
ct matte
r in
this document. Except as expressly prov ided in any written license agreement f rom Microsof t, the f urnishing of this document
does not
giv e y ou any license to these patents, trademarks, copy rights, or other intellectual property.

© 200
9

Microsof t Corporation. All rights reserv ed.