Load Runner Versions:

8.0, 8.1, 9.0, 9.1, 9.5 and 11

Load Runner version 11.0 supports windows operating system.
Load Runner 9.5
Released in 2009
New Features
Protocol Advisors
Newly added array functions
Load Runner Components:
1. VU Generator: used to generate/develop/enhance the vuser business scripts for all
the scenarios which are in scope c language.
2. Controller : used to execute scripts with multiple users
3. Analysis: Validate the test execution results with the expected behavior i.e. (SLA)
4. Load Generator: It generates the amount of vusers to run on the server.
5. Agent Process: It establishes a communication between the load generator and
controller
Virtual User Generator Controller load generator agent process analysis
Virtual user Generator:

This component is used to generate the script for each business process or scenario with the
supported protocol.

Protocol Advisor:

This is a new feature of Load Runner 9.5 and it identifies the supported protocols by the application
under test or the business process.
WebTours URL
http://127.0.0.1:1080/WebTours/
username/password : jojo/bean
By using a protocol advisor, we identified the below types of protocols that supports for the application
business proces.
Ajax (click and script)
Web (HTTP/HTML)
Selecting an appropriate protocol:
1. Protocol advisor has identified two protocols supported by application under test but we have
to use only one protocol for performance testing.
2. It would be better to go with Web protocol first and then go for ajax if it does not support web
lets
3. The reasons to select web protocol is quite obvious, the licence cost for generating virtual
users is of ration 1:10 for web and ajax and also memory constraints, Web protocol consume
2MB where as Ajax protocol consumes 10 MB per virtual user
Select the protocol as web (HTTP/HTML) to generate the script:

Recording Modes:

Load Runner has two types of recording modes

HTML Based Recording:

1.
2.

It generates the script for HTML Source of the web page.

Generates web vuser functions for each user action on the web page

3.

Functions in html recording are web_link, web_submit_form, web_url, web_submit_data

URL Based Recording:

1. It generates script for non html resources like .jpg, .bmp, .gif and css files.
2.
3.

It generates separate web functions for each non html resource on a web page.
Functions it supports are Web_url, web_submit_url, web_custom_request

Note: It is recommended to user html based recording over url based recording as it focuses on user
actions.

Correlation:

Correlation is handle the data generated by server

There are two types of correlation process that supports load runner.

Automatic Correlation

Manual Correlation
Automatic Correlation: Handle server generated data with the help of tool functionalities is called
automatic correlation
1. Scan script for correlation generate the script for end to end business scenario, run the script
and I observed a problem in handling sessions ids generated by the script ie an error with
session while logging into application.
2. Select > View > Scan Script for correlation> The differentiate values between the recording
and replay will display under correlation results

3.
4.
5.

Select the value and click correlate

It will automatically insert the correlated function with all the arguments
The correlation function web_reg_save_param( "WCSParam_Diff1", "LB=userSession value=",
"RB=>", "Ord=3", "IgnoreRedirections=Yes", "Search=Body", "RelFrameId=1.2.1", LAST );)

Second method: creating a correlation rule

1.
2.
3.
4.
5.
6.

Enable correlation in recording settings

Create new application and create new rule
Assign the left boundary and right boundary values and define the ORD number
Generate the script with end to end business actions
It will automatically insert the correlation function with all the arguments doing the script
recording
When u reply the script, it should successfully run without any session issues

Manual Correlation:
1.

Identify correlated values: record same scenario twice and save each script. Go to
Tools>Compare with Script from one of the saved scripts, a dialog will open, now select the
other script. A file with differences between the two scripts is displayed ie..Wdiff. From the
Wdiff we can figure out the values that could be correlated. The differences are are highlighted
in yellow lines.

Identify the required correlated value from the differences, important thing to note while
comparison is that only server generated values have to be considered for correlation, not all the
differences such as think time, x-y co-ordinates.
2.

Capture the server generated value: use correlated function web_reg_save_Param()

web_reg_save_param( "ParamName", "LB= ", "RB=>", "Ord=", "IgnoreRedirections=Yes",
"Search=Body", "RelFrameId=", LAST );)
The sessionid or session value is generated by the server, in order to capture the server
generated value, we have to search in the previous client request, ie.. say in the script a
function is requesting the server with a session value, this is sent by client to server, so in
order to pass the session id dynamically to the current function, we have to go to the previous
function in the script.
Copy the identified correlated value, Go to view > Tree

Search for the correlated value in the response, identify the left boundary and right boundary
of the correlated value.

Then identify the ordinal value of the correlated value, ie. Search if there are similar tags
existing in the response with same left and right boundary, if exists then list them down in the
notepad.
Then, the position in which the correlated value is nothing but ord value
Go to script view, insert the correlated function with all the arguments before the previous
request.
web_reg_save_param("sessionID","LB=<input type=hidden name=userSession
value=","RB=>","ORD=3",LAST);
3.
4.

When you replay the script the given parameter will capture the data at run time
Save it into variable: By default it saves the new value into the given parameter for a specific
ord number
ii) we need to save a required value into the separate variable whenever ord = all
Replace the variable at all the places of original values in the script.
Replay the script and verify the log as well as results file

Correlated Functions Arguments:

Correlated function lr_reg_save_parm() can save into a variable or an array based on ord value
if the ord value is specific say 1 then the value would be saved into a vaiable. If ord is all ie..
ord=all then, the values would be stored as array
Arguments:
a. Parameter name: It Saves the data matching the given boundary
b. LB: It is the left boundary of the correlated data
c. RB: It is the right boundary of the correlated data
d. ORD: it is the ordinal value of the correlated data, It defines a position or occurrence of the
correlated value between the give left and right boundaries
Example: ORD=1, it captures the first position value between the given boundaries.
ORD=2 It captures the second position value between the given boundaries.
ORD=all It captures all the position values between the given left and right boundaries.

Randomly selecting values from load runner parameter or correlation array

parameter

When you user ord = all, correlated parameter captures list of values in an array. So, use the
below randomized function to select the random value from the array. It captures a specific index value
from the array list
lr_parmarr_idx(arrayparameter, index)
lr_parmarr_random(arrayparameter) It takes a random value from the available array range
lr_paramarr_len (arrayparameter) Returns the length of the array passed as parameter
Note: all the above array functions are available from loadrunner 9.5
1.
2.

To calculate the length of the given array use the below syntax
arrPrmcnt = atoi(lr_eval_string(arrayparm_count));
cityCount = atoi(lr_eval_string("{city_count}"));
To select a random value from the available range use the below syntax
cityCount = atoi(lr_eval_string("{city_count}"));
city:
rndNum1 = rand()%cityCount+1;
rndNum2 = rand()%cityCount+1;
sprintf(fromCityParm,"{city_%d}",rndNum1);
sprintf(toCityParm,"{city_%d}",rndNum2);
sprintf(toCity,"%s",lr_eval_string(toCityParm));

Parameterization:
Passing different set of inputs instead of original values in the script

Sequential each iteration: Parameterize a value in the script, ie.. select a value in the script,
right click on the value and select replace with parameter, a dialog opens with multiple options, enter
the parameter name and select file as parameter type.

GoTo > vusers>Parameters list, a dialog with all the parameters would be listed. Select the
parameter created above, and click edit with note pad option and give multiple values and then save
it. All the multiple values given in the note pad are reflected in the parameter list dialog.

Then select next row as sequential and update value on as each iteration and then click
Simulate Parameter button.
Parameter simulation daialog is opened.

Select number of virtual users and Number of iternations to run and click on simulate button.

If above screen shot is observed, for each iteration the vusers are same, this is the drawback of
sequential iterations iefor each iteration the vuser would be sequentially assigned but the vusers are
same in each iteration.
Sequential Once
Then select next row as sequential and update value on as Once and then click Simulate
Parameter button.A single sequential parameter value will be assigned for all the iterations done by
the vuser
Note: In all the sequential combinations the data which is passed for the first vuser, the same
date would be assigned to remaining vusers.

Random each iteration:

Then select next row as Random and update value on as Each Iteration and then click
Simulate Parameter button. The new random parameter value will be updated for each iteration of
the script execution ie.. the parameter value passed for a virtual user is different in each iteration.

Random Once:
Then select next row as Random and update value on as Once and then click Simulate
Parameter button.
A single random parameter value would be assigned for all the iterations done by the vuser

Unique each iteration

Select next row as Unique and update value on as Each Iteration and then click
Simulate Parameter button. Here, additional options are enabled in the parameter list dialog.
Allocate Vuser values in the controller would be enabled. This is where we allocate the block size,
when we say we want unique value for a vuser that means a value given for a vuser should be unique
across iterations and should not be used by the other vusers.
So if we mention the range for each vuser ie nothing but block size, say if we select Allocate value for
each vuser, as 10 first vuser would be assigned 1-10 valules from the file, the next vuser would be
assigned values from 11-20 in the file and so on..
If we select Autmatically allocate block size, load runner itself would allocate the block size based on
number of iterations.
The unique parameter value would be assigned for each iteration of the script execution

Block Size:
Allocate the block size for each user based on the iterations
File Size:
Allocate the parameter values in a file based on number of users and iterations for example if
there are 5 vusers in 10 iterations, the file size should be 5*10 i.e. 50
Unique Once
A single parameter value would be assigned for all the iterations done by the vuser

Each Occurrence: When same Parameter is used multiple times in an action, each occurrence would
send different data for every occurrence.

It would update a new parameter value for each occurrence of the parameter file in the script.

Multi column Datafiles:

It supports the parameter file types as .dat, .txt, .csv

Transaction Points:
Insert transaction points to measure the response time of user actions.

Start Transaction:
lr_start_transaction(*char parmName):
ApplicationName_ScenarioName_TransactionNum_Action

End Transaction:
Lr_end_transaction(transactionname,status):
LR_AUTO: Automatically returns the status of end transaction, either pass or fail or stop.
LR_PASS: Returns the status as PASS
LR_FAIL: Returns the status as FAIL

Check Points:
Two types of check points are available in load runner

Text Check Point Validates the given text on a web page using two functions
Web_reg_find(textToFind) : One type of check function to validate, this function we user
savecount argument to capture the occurrence of the given text on a web page.
Web_find(): It is also one type of text check functions to validate the given text on a
web page.
Syntax: Web_find(stepname,what=textToVerifty,LAST)

Web_reg_find
It records the title of the page by default
by havig advance option in record setting
This function is written before the action
functions or befor requesting server
No need to enable any option to verify
during script run or play back

Image Check Point

web_find
No option is available to record the text by
default during script recording
This function is written after the action
functions or after requesting server
We need to enable, Image and text check in
Runtime Settings > Internet Protocol>
Preferences > Enable Image and text check

CONTROLLER:
In this component we will design and execute the multi user performance business secenarios
There are two types of scenarios can be designed in load controller scenario.
1) Manual Scenario
2) 2) Goal Oriented Scenario

Manual Scenario:
Create the controller scenario based on the number of virtual users
Goal Oriented Scenario:
Create the controller scenario based on the below specified goal
Goal Types:

1.
2.
3.
4.
5.

Virtual Users
Hits per Second
Transactions per Second
Transaction Response Time
Pages per Minute

Execution Process or Summary:

1.
2.
3.

Upload all the scripts into the controller which are in scope.
Define the vuser load for each script(user mix)
Assign the load generator to generate vusers load(How many users should be generated on a
load generator?)
How do you define how many load generators to be used, and how many users should be used
on the generator?
Load generators gernerates the amount of vusers to run the script to simulate real word
behavior. Based on system configuration of load generator machine generates the load from
each load generator.
Configuration: for web protocol the recommended users are 1 for 2MB of RAM and for 2GB 500
members. 50% of the memory is used for virtual users and 50% for services to run.
Load generator can be configured either in windows or in Unix
We can configure load generator from other machines in a controller. Some times its fail to
connect to the destination PCs load runner the possible reasons could be either the machine
with the given ip address is not started or the agent process software is either not installed or
not running on the destination machine.
Assigning the multiple load generators into a single script:
a. We will add the same script and assign each load generator
b. We will assign the multiple load generators into a single line of script using a coma
separator
Select the script, click on

Load runner VTS(Virtal Table Server): we want to run single script on three different
generators, we place the user data on vts server. When first vuser of the first load
generator he picks the usernames from the vts server but when the second vuser comes,

4.

the first user in vts table gets deleted and second vuser would replace it and the vuser
takes the first row.
Define the standard runtime settings for each script
a) Run Logic: To Define the number of iterations for Actions not and it will not be applicable
for Init and End method of the script.

Block Iterations:
Number iterations set above ie 20 is applicable for all the action, the above script has only
one action even if there are multiple actions in the script the same number of iterations are
applicable to the actions.
Running different actions in the script with different iterations, to do that first delete all the
actions from the run time settings, I mean only from run time settings, not from the script.
Then insert blocks equal to the number of actions in the script using Insert Block button,
now right click on the block and insert one action each.
After inserting actions to the blocks, right click the action and select Properties option, then
the in the dialog box displayed give the block iterations.

Pacing:
It is the user waiting time between the iteration executions.

Log:
It captures the behavior of script execution into a log file,
Note: The recommended log option is send messages only when an error orrurs.

Think Time:
Its a user waiting time between the transaction executions.

Miscellaneous:
1.

Error Handling
a. Continue on error
b. Fail open transactions on lr_error_message
c. Generate Snapshot on error

It is recommended to select the option Generate Snapshot on error

2.

Multithreading
a. Run Vuser as a process In process oriented communication; each vuser will be
generated using a separate driver program.
It consumes more system resources, for multiple .exes

b.

Run Vuser as a thread In thread communication, a single driver program is

created for all vusers in the system. It consumes low system resources as single
driver program is created from all VUsers.

Note: Its always recommended to select run user as a thread option.

Speed Simulation: In this we can select the bandwidth to user in the executions.

Browser Emulation:

In this we can define all the browser level enhancements

1.
2.
3.

Simulate Browser Cache

a. Cache URLs requiring cintent(HTMLs)
b. Check for newer versions of stored pages every visit on the page.
Download non-HTML resources
Simulate a new user on each iteration
a. Clear cache on each iteration

Proxy:
A proxy is a middleware server to validate the request and responses from one network to another
network

Preferences:

Advanced options has the following important timeouts

Download filters:
1.

User the filter to block unnecessary URLs in the execution

Content Check: It is used to verify the given text on all the user accessing web pages
5.

6.

Defien RampUp time: RampUp- It initializes the vusers and server with the given interval time.
We can set rampup from the
Simultaneously: It initializes all the vusers on the server at the same time
Slow RampUp: It initializes the given amount of users on server with the specified interval time
We can give the ramp up by clicking on start vusers in the global schedule.Z
Note: Always the recommended option is slow rampup
Define the steady state period to run all vusers on server
Run until completion: it runs vusers on server until completion of the iterations.
Note: We need to define the fixed number of iterations to design the scenario for run until
completion.
Run for duration: It runs all the vusers on server with the given time duration.

Note: In this case its not necessary to specify iterations because it will automatically repeat
the iteration for given time duration.
7.

RampDown Define ramp down(stop vusers)

It downs the vusers from server using the below two options.
1. Simultaneous ramp down, slow ramp down

10. Configure the project SLA (Service Level Agreement)

1. Click New in Service Level Agreement
Then proceed with selecting multiple options based on the need.
11. Save the results
Click on Results settings
Save the results with the following format
ApplicationName_Load_PerfTestType_Date

ArabianBank_100Users_LoadTest_12072011
Ip Spoofing:
It assigns one ip address to each virtual user running in the execution.
a.
b.

Generate the required number of ip addresses in corresponding load generator

Enable ip spoofer in load controller scenario ie.. Scenario > Enable Ip Spoofer in load
controller scenario

Server Side Metrics Configuration:

System level monitors and server level monitoring:
Windows System Monitor:
1.
2.
3.
Object
Proces
sor

Select Windows Resources option under Available graphs or drag the option and drop it on the
graph
Right click on the Windows Resources option, select Add Measurements option
Addd Server machine details in Window Resources dialog, i.e..ipaddress and login details of
the system in which the server is set up.
Counters
% idle time
% privileged
time

% processor
time

% user time

Interrupts/sec

Description
% Idle Time is the percentage of time the processor is idle during the
sample interval
% Privileged Time is the percentage of elapsed time that the process
threads spent executing code in privileged mode. When a Windows
system service in called, the service will often run in privileged mode to
gain access to system-private data. Such data is protected from access by
threads executing in user mode. Calls to the system can be explicit or
implicit, such as page faults or interrupts. Unlike some early operating
systems, Windows uses process boundaries for subsystem protection in
addition to the traditional protection of user and privileged modes. Some
work done by Windows on behalf of the application might appear in other
subsystem processes in addition to the privileged time in the process.
% Processor Time is the percentage of elapsed time that the processor
spends to execute a non-Idle thread. It is calculated by measuring the
duration of the idle thread is active in the sample interval, and subtracting
that time from interval duration. (Each processor has an idle thread that
consumes cycles when no other threads are ready to run). This counter is
the primary indicator of processor activity, and displays the average
percentage of busy time observed during the sample interval. It is
calculated by monitoring the time that the service is inactive, and
subtracting that value from 100%.
% User Time is the percentage of elapsed time the processor spends in the
user mode. User mode is a restricted processing mode designed for
applications, environment subsystems, and integral subsystems. The
alternative, privileged mode, is designed for operating system components
and allows direct access to hardware and all memory. The operating
system switches application threads to privileged mode to access
operating system services. This counter displays the average busy time as
a percentage of the sample time.
Interrupts/sec is the average rate, in incidents per second, at which the
processor received and serviced hardware interrupts. It does not include
deferred procedure calls (DPCs), which are counted separately. This value
is an indirect indicator of the activity of devices that generate interrupts,
such as the system clock, the mouse, disk drivers, data communication
lines, network interface cards, and other peripheral devices. These devices
normally interrupt the processor when they have completed a task or
require attention. Normal thread execution is suspended. The system clock
typically interrupts the processor every 10 milliseconds, creating a

Memor
y

Available
Mbytes

Committed
Bytes

% Committed
Bytes in use

Page
Faults/sec

Page
reads/sec

Page
writes/sec

Page
Input/sec

Page
Output/sec

background of interrupt activity. This counter displays the difference

between the values observed in the last two samples, divided by the
duration of the sample interval.
Available MBytes is the amount of physical memory, in Megabytes,
immediately available for allocation to a process or for system use. It is
equal to the sum of memory assigned to the standby (cached), free and
zero page lists. For a full explanation of the memory manager, refer to
MSDN and/or the System Performance and Troubleshooting Guide chapter
in the Windows Server 2003 Resource Kit.
Committed Bytes is the amount of committed virtual memory, in bytes.
Committed memory is the physical memory which has space reserved on
the disk paging file(s). There can be one or more paging files on each
physical drive. This counter displays the last observed value only; it is not
an average.
% Committed Bytes In Use is the ratio of Memory\\Committed Bytes to the
Memory\\Commit Limit. Committed memory is the physical memory in use
for which space has been reserved in the paging file should it need to be
written to disk. The commit limit is determined by the size of the paging
file. If the paging file is enlarged, the commit limit increases, and the ratio
is reduced). This counter displays the current percentage value only; it is
not an average.
Page Faults/sec is the average number of pages faulted per second. It is
measured in number of pages faulted per second because only one page
is faulted in each fault operation, hence this is also equal to the number of
page fault operations. This counter includes both hard faults (those that
require disk access) and soft faults (where the faulted page is found
elsewhere in physical memory.) Most processors can handle large numbers
of soft faults without significant consequence. However, hard faults, which
require disk access, can cause significant delays.
Page Reads/sec is the rate at which the disk was read to resolve hard page
faults. It shows the number of reads operations, without regard to the
number of pages retrieved in each operation. Hard page faults occur when
a process references a page in virtual memory that is not in working set or
elsewhere in physical memory, and must be retrieved from disk. This
counter is a primary indicator of the kinds of faults that cause system-wide
delays. It includes read operations to satisfy faults in the file system cache
(usually requested by applications) and in non-cached mapped memory
files. Compare the value of Memory\\Pages Reads/sec to the value of
Memory\\Pages Input/sec to determine the average number of pages read
during each operation.
Page Writes/sec is the rate at which pages are written to disk to free up
space in physical memory. Pages are written to disk only if they are
changed while in physical memory, so they are likely to hold data, not
code. This counter shows write operations, without regard to the number
of pages written in each operation. This counter displays the difference
between the values observed in the last two samples, divided by the
duration of the sample interval.
Pages Input/sec is the rate at which pages are read from disk to resolve
hard page faults. Hard page faults occur when a process refers to a page
in virtual memory that is not in its working set or elsewhere in physical
memory, and must be retrieved from disk. When a page is faulted, the
system tries to read multiple contiguous pages into memory to maximize
the benefit of the read operation. Compare the value of Memory\\Pages
Input/sec to the value of Memory\\Page Reads/sec to determine the
average number of pages read into memory during each read operation.
Pages Output/sec is the rate at which pages are written to disk to free up
space in physical memory. Pages are written back to disk only if they are
changed in physical memory, so they are likely to hold data, not code. A
high rate of pages output might indicate a memory shortage. Windows
writes more pages back to disk to free up space when physical memory is

Pages/sec

Pool
Nonpaged
Allocs

Pool
Nonpaged
Bytes

Pool Paged
allocs

Pool paged
Bytes

Physica
l disk

% disk time
% idle time
Avg. disk read
queue length
Avg. disk
write queue
length
Current disk
queue length

Proces
s

% processor
time

in short supply. This counter shows the number of pages, and can be
compared to other counts of pages, without conversion.
Pages/sec is the rate at which pages are read from or written to disk to
resolve hard page faults. This counter is a primary indicator of the kinds of
faults that cause system-wide delays. It is the sum of Memory\\Pages
Input/sec and Memory\\Pages Output/sec. It is counted in numbers of
pages, so it can be compared to other counts of pages, such as
Memory\\Page Faults/sec, without conversion. It includes pages retrieved
to satisfy faults in the file system cache (usually requested by
applications) non-cached mapped memory files.
Pool Nonpaged Allocs is the number of calls to allocate space in the
nonpaged pool. The nonpaged pool is an area of system memory area for
objects that cannot be written to disk, and must remain in physical
memory as long as they are allocated. It is measured in numbers of calls
to allocate space, regardless of the amount of space allocated in each call.
This counter displays the last observed value only; it is not an average.
Pool Nonpaged Bytes is the size, in bytes, of the nonpaged pool, an area of
system memory (physical memory used by the operating system) for
objects that cannot be written to disk, but must remain in physical
memory as long as they are allocated. Memory\\Pool Nonpaged Bytes is
calculated differently than Process\\Pool Nonpaged Bytes, so it might not
equal Process\\Pool Nonpaged Bytes\\_Total. This counter displays the last
observed value only; it is not an average.
Pool Paged Allocs is the number of calls to allocate space in the paged
pool. The paged pool is an area of system memory (physical memory used
by the operating system) for objects that can be written to disk when they
are not being used. It is measured in numbers of calls to allocate space,
regardless of the amount of space allocated in each call. This counter
displays the last observed value only; it is not an average.
Pool Paged Bytes is the size, in bytes, of the paged pool, an area of system
memory (physical memory used by the operating system) for objects that
can be written to disk when they are not being used. Memory\\Pool Paged
Bytes is calculated differently than Process\\Pool Paged Bytes, so it might
not equal Process\\Pool Paged Bytes\\_Total. This counter displays the last
observed value only; it is not an average.
% Disk Time is the percentage of elapsed time that the selected disk drive
was busy servicing read or write requests.
% Idle Time reports the percentage of time during the sample interval that
the disk was idle.
Avg. Disk Read Queue Length is the average number of read requests that
were queued for the selected disk during the sample interval.
Avg. Disk Write Queue Length is the average number of write requests
that were queued for the selected disk during the sample interval.
Current Disk Queue Length is the number of requests outstanding on the
disk at the time the performance data is collected. It also includes
requests in service at the time of the collection. This is a instantaneous
snapshot, not an average over the time interval. Multi-spindle disk devices
can have multiple requests that are active at one time, but other
concurrent requests are awaiting service. This counter might reflect a
transitory high or low queue length, but if there is a sustained load on the
disk drive, it is likely that this will be consistently high. Requests
experience delays proportional to the length of this queue minus the
number of spindles on the disks. For good performance, this difference
should average less than two.
% Processor Time is the percentage of elapsed time that all of process
threads used the processor to execution instructions. An instruction is the
basic unit of execution in a computer, a thread is the object that executes
instructions, and a process is the object created when a program is run.
Code executed to handle some hardware interrupts and trap conditions

Private bytes
Virtual bytes

Working set

System

Processor
queue length

Processes

Threads

TCPv4

Connection
failures

Connections
active
Connections
established

are included in this count.

Private Bytes is the current size, in bytes, of memory that this process has
allocated that cannot be shared with other processes.
Virtual Bytes is the current size, in bytes, of the virtual address space the
process is using. Use of virtual address space does not necessarily imply
corresponding use of either disk or main memory pages. Virtual space is
finite, and the process can limit its ability to load libraries.
Working Set is the current size, in bytes, of the Working Set of this process.
The Working Set is the set of memory pages touched recently by the
threads in the process. If free memory in the computer is above a
threshold, pages are left in the Working Set of a process even if they are
not in use. When free memory falls below a threshold, pages are trimmed
from Working Sets. If they are needed they will then be soft-faulted back
into the Working Set before leaving main memory.
Processor Queue Length is the number of threads in the processor queue.
Unlike the disk counters, this counter counters, this counter shows ready
threads only, not threads that are running. There is a single queue for
processor time even on computers with multiple processors. Therefore, if a
computer has multiple processors, you need to divide this value by the
number of processors servicing the workload. A sustained processor queue
of less than 10 threads per processor is normally acceptable, dependent of
the workload.
Processes is the number of processes in the computer at the time of data
collection. This is an instantaneous count, not an average over the time
interval. Each process represents the running of a program.
Threads is the number of threads in the computer at the time of data
collection. This is an instantaneous count, not an average over the time
interval. A thread is the basic executable entity that can execute
instructions in a processor.
Connection Failures is the number of times TCP connections have made a
direct transition to the CLOSED state from the SYN-SENT state or the SYNRCVD state, plus the number of times TCP connections have made a direct
transition to the LISTEN state from the SYN-RCVD state.
Connections Active is the number of times TCP connections have made a
direct transition to the SYN-SENT state from the CLOSED state.
Connections Established is the number of TCP connections for which the
current state is either ESTABLISHED or CLOSE-WAIT.

Step10. Configure the project SLAs

Step11. Save the results

IP spoofing

It assigns one IP address for each user running in the execution.

1. Generate the required number of IP addresses in corresponding load
generator
2. Enable IP Spoofer in load controller scenario
Server side metric configuration
System/OS/Hardware level metrics
Windows system:

Object
Processor

Memory

Counters
% idle time
% privileged time
% processor time
% user time
Interrupts/sec
Available Mbytes
Committed Bytes
% Committed Bytes in use

Instances
All instances

No instances

Physical disk

Process

System
TCPv4

Page Faults/sec
Page reads/sec
Page writes/sec
Page Input/sec
Page Output/sec
Pages/sec
Pool Nonpaged Allocs
Pool Nonpaged Bytes
Pool Paged allocs
Pool paged Bytes
% disk time
% idle time
Avg. disk read queue
length
Avg. disk write queue
length
Current disk queue length
% processor time
Private bytes
Virtual bytes
Working set
Processor queue length
Processes
Threads
Connection failures
Connections active
Connections established

All instances

All instances

No instances
No instances

System level monitoring using Perfmon

UNIX OS Level Monitory

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

CPU Utilization
System Mode CPU Utilization
User mode CPU utilization
Interrupt rate
Page in Rate
Page out rate
Paging rate
Memory
Swap in rate
Swap out rate
Average Load
Collision Rate
Context switch rate
Disk Traffic
Incoming Packets error rate
Incoming packets rate
Outgoing Packets error rate
Outgoing packets rate

Counter
CPU Utilization

Description
Percent of time that the CPU is utilized.

System Mode CPU

Utilization

Percent of time that the CPU is utilized in system mode.

User mode CPU utilization

User mode CPU utilization
Page in Rate
Page out Rate

Percent of time that the CPU is utilized in user mode..

Number of device interrupts per second.
Number of pages read to physical memory, per second.
Number of pages written to pagefile(s) and removed from physical
memory, per second.
Number of pages read to physical memory or written to pagefile(s),
per second.
Number of processes being swapped-in to memory, per second.
Number of processes being swapped-out from memory, per second.
Average number of processes simultaneously in Ready state during
the last minute.
Collisions per second detected on the Ethernet.
Number of switches between processes or threads, per second.
Rate of disk transfers.
Errors per second while receiving Ethernet packets.

Paging Rate
Swap-in-rate
Swap-out-rate
Average Load
Collision Rate
Context Switch Rate
Disk Traffic
Incoming Packets error
rate
Incoming Packets rate
Outgoing Packets error
rate
Outgoing Packets rate

Number of device interrupts per second.

Errors per second while sending Ethernet packets.
Outgoing Ethernet packets per second.

Note: To collect the UNIX resources through a controller, rstat daemon process should run in Unix box.
Note: UNIX does not have a built in utility to monitor the counters, we have to run different scripts in
Unix to monitor the performance counters.
Unix Performance Monitoring using shell files:
1.
2.
3.
4.

Connect to the UNIX box using a putty

Go to the directory where the monitory scripts are located
Run all the .sh files before starting of the execution
It collects the separate log files for each individual .sh file

Note: To Copy the data from Unix machine to Windows machine and vice versa use WinScp utility.