Load Runner Performance Testing

HP Performance Center (Load Runner)
Performance testing by using Load Runner
Manoj Xerox
Cell:8978989710
HP Load Runner by Satyam QEdge Performance SO, Hyderabad

1
1.0 Performance Testing

Performance testing is aimed at verifying the system’s performance requirements
like response time, transactional throughput and number of concurrent users.
Performance testing is used to accurately measure the end-to end performance of a
system prior to go live.
It includes the following:
• Emulating ‘n’ number of users interacting with the system using minimal
hardware.
• Measuring End-User’s Response time.
• Repeating the load consistently
• Monitoring the system components under controlled load.
• Providing robust analysis and reporting engines
1.1 Why Performance testing?

To verify the below mentioned:
• Application’s response for the intended number of users
• Application’s maximum load resisting capacity
• Application’s capacity of handling the number of transactions required by
the Business
• Application’s stability under expected and unexpected user load
• Ensuring that users have proper response time on production
1.2 Execute
Execution will be done in multiple phases. It consists of various types of testing like
Baseline Testing
This testing is done to ensure that both applications’ functionality & environment
setup for performance testing is proper. This will be done with 10 to 20 users.
Performance Tests
This includes running the scripts with Average and Maximum load with specified no
of transactions. We will be simulating the real time environment with different load
conditions using different Scenarios, Think Time, Pace Time and no. of users.

2
Benchmark Tests
These are designed to measure and compare the performance of each machine type,
environment or build of the application in ideal situation. These tests are run after
the system undergoes scalability testing to understand the performance impact of
different architectures.
Analysis and Tuning
During the performance testing we will be capturing all the details related to the
system like Response time and System Resources for identifying the major
bottlenecks of the system. After the bottlenecks are identified we have to tune the
system to improve the overall performance.
Performance Optimization
This quantifies to improve the performance of the system as measured by improved
end-user response time or by reducing the overall required hardware infrastructure.
1.3 Performance Testing using “LESS” Approach

1.3.1 Load Testing
Load tests are performance tests, which are focused on determining or validating
performance characteristics of the product under test when subjected to workload
models and load volumes anticipated during production operations.
What are the benefits?
• Evaluate the adequacy of a load balancer.

• Detecting functionality errors under load.
• Determine the scalability of the application OR for capacity planning purposes
as the need may be.
What risks does it address?
• How many users can the application handle before “bad stuff” happens
• How much data can my database/file server handle?
• Are the network components adequate?
• Many users requesting a certain page at the same time or using the site
simultaneously.
• Increase the number of users and keep the data constant.

3
• Does the home page load quickly? Within 8 seconds.
• Is load time appropriate to content, even on a slow dial-in connection?
• Can the site sustain long periods of usage by multiple users
• Can the site sustain long periods of continuous usage by 1 user?
• Is page loading performance acceptable over modems of different speeds?
• Does the system meet its goals for response time, throughput, and
availability?
• Have you defined standards for response time (i.e. all screens should paint
within 10 seconds)?
• Does the system operate in the same way across different computer and
network configurations, platforms and environments, with different mixes of
other applications?
1.3.2 Endurance Testing
A performance test focused on determining or validating performance characteristics

of the product under test when subjected to workload models and load volumes
anticipated during production operations over an extended period of time.
• Slow memory leaks

• Insufficient file storage capacity
• Performance degradation as a result of an increased in stored data
• Overnight, automatic virus definition updates on a server causing
performance degradation
1.3.3 Stress testing
Performance tests focused on determining or validating performance characteristics

of the product under test when subjected to workload models, and load volumes
beyond those anticipated during production operations.
These tests are all about determining under what conditions an application will fail
how it will fail and what indicators can be monitored to warn of an impending failure.

4
• Determining if data can be corrupted by over stressing the system

• Estimating how far beyond the target load an application can go before
causing failures and errors in addition to slowness
• Establishing application-monitoring triggers to warn of impending failures.
• Ensuring that security holes are not opened up by stressful conditions.
• Determining the side effects of common hardware or supporting application
failures.
1.3.4 Spike Testing
A performance test focused on determining or validating performance characteristics

of the product under test when subjected to workload models and load volumes that
repeatedly increase beyond anticipated production operations for short periods of
time. It identify the
• Memory leaks
• Disk I/O (thrashing)
• Slow return to steady – state
1.4 Scalability testing:

Scalability testing integrates very well with performance testing. The purpose of
scalability testing is to determine whether the application automatically scales to
meet the growing user load.
1.5 Volume testing

To verify the stability of the system with respect to handling large amounts of data
over extended period of time.
What are the benefits ?
• Increase the data by having constant users.
• Will the site allows for large orders without locking out inventory if the
transaction is invalid.
• Can the site sustain for large transactions without crashing?

5
1.6 Capacity Testing
Capacity testing is related to stress testing .It determines your server's ultimate
failure point. You perform capacity testing in conjunction with capacity planning.
You use capacity planning to plan for future growth, such as an increased user base
or increased volume of data.
• Conduct various tests to compare capacity planning models and/or

predictions.
• Determine current usage and capacity of existing system to aid in capacity
planning.
• Provide usage and capacity trends of existing system to aid in capacity
planning.

6
2.0 Introduction to Load Runner

Load runner enables you to test your system under controlled and peak load
conditions. To generate load, Load Runner runs thousands of Virtual Users that are
distributed over a network.
Using a minimum of hardware resources, these Virtual Users provide consistent,

repeatable, and measurable load to exercise your application just as real users
would. Load Runner’s in-depth reports and graphs provide the information that you
need to evaluate the performance of your application.
Load Runner emulates an environment in which thousands of users work with a

client/server system concurrently. To do this, Load Runner replaces the human user
with a virtual user (Vuser). The actions that the Vusers perform are described in a
Vuser Script.
2.1 The Load Runner advantages over Manual performance testing:

• Load Runner reduces the personnel requirements by replacing human users
with virtual users or Vusers. These Vusers emulate the behavior of real
users— operating real applications.
• Because numerous Vusers can run on a single computer, Load Runner
reduces the hardware requirements.
• The Load Runner Controller allows you to easily and effectively control all the
Vusers—from a single point of control.
• Load Runner monitors the application performance online, enabling you to
fine-tune your system during test execution.
• Load Runner automatically records the performance of the application during
a test. You can choose from a wide variety of graphs and reports to view the
performance data.
• Load Runner checks where performance delays occur: network or client
delays, CPU performance, I/O delays, database locking, or other issues at the
database server. Load Runner monitors the network and server resources to
help you improve performance.
• Because Load Runner tests are fully automated, you can easily repeat them
as often as you need.

7
2.2 Components of Load Runner
They are 4 components available in Load Runner they are
A. Virtual User Generator (Vugen)
B. Load Controller.
C. Load Generator / Host.
D. Analysis.
Vugen
Generating the script, recording the script, transactions and Rendezvous points.
Vugen is used to monitor the communication between the application and the server.
Controller
You use the Load Runner Controller to manage and maintain your scenarios. Using
the Controller, you control all the Vusers in a scenario from a single workstation.
Load generator
When you execute a scenario, the Load Controller distributes each Vuser in the
scenario to a load generator. The load generator is the machine that executes the
Vuser script, enabling the Vuser to emulate the actions of a human user.
Analysis
Vuser scripts include functions that measure and record system performance during
load-testing sessions. During a scenario run, you can monitor the network and server
resources. Following a scenario run, you can view performance analysis data in
reports and graphs.

8
2.3 Load Runner Architecture overview
Load Runner works by creating virtual users who take the place of real users
operating client software, such as Internet Explorer sending requests using the
HTTP protocol to IIS or Apache web servers. Requests from many virtual user clients
are generated by "Load Generators" in order to create a load on various servers
under test. These load generator agents are started and stopped by Mercury's
"Controller" program. The Controller controls load test runs based on "Scenarios"
invoking compiled "Scripts" and associated "Run-time Settings". Scripts are crafted
using Mercury's "Virtual user script Generator" (named "V U Gen"), It generates C-
language script code to be executed by virtual users by capturing network traffic
between Internet application clients and servers. With Java clients, VuGen captures
calls by hooking within the client JVM. During runs, the Controller monitors the
status of each machine. At the end of each run, the Controller combines its
monitoring logs with logs obtained from load generators, and makes them available
to the "Analysis" program, which can then create run result reports and graphs for
Microsoft Word, Crystal Reports, or an HTML webpage browser. Each HTML report
page generated by Analysis includes a link to results in a text file, which Microsoft
Excel can open to perform additional analysis.

9
2.4 How Load Runner Works
2.5 Load Runner Vuser Types

Load Runner has various types of Vusers. Each type is designed to handle different
aspects of today’s system architectures. You can use the Vuser types in any
combination in a scenario in order to create a comprehensive application test. The
following Vuser types are available:
• Client/Server: For MSSQLServer, ODBC, Oracle (2-tier), DB2 CLI, Sybase

Ctlib, Sybase Dblib, Windows Sockets and DNS protocols.
• Custom: For C templates, Visual Basic templates, Java templates, Javascript
and VBScript type scripts.
• Distributed Components: For COM/DCOM, Corba-Java, and Rmi-Java
protocols.
• E-business: For FTP, LDAP, Media Player, Multi Protocol Web/WS, Web
(HTTP, HTML), Palm, and RealPlayer protocols.
• Enterprise Java Beans: For EJB Testing and Rmi-Java protocols.
• ERP: For Oracle NCA, Peoplesoft (Tuxedo), SAP, and Siebel protocols.
• Legacy: For Terminal Emulation (RTE).

10
• Mailing Services: Internet Messaging (IMAP), MS Exchange (MAPI), POP3,
and SMTP.
• Middleware: For the Tuxedo (6, 7) protocol.
• Wireless: For i-Mode, VoiceXML, and WAP protocols.
2.6 Some of the most commonly used terms in the Load Runner
Scenarios
Using Load Runner, you divide your application performance testing requirements
into scenarios. A scenario defines the events that occur during each testing session.
Thus, for example, a scenario defines and controls the number of users to emulate,
the actions that they perform, and the machines on which they run their emulations.
Transactions
Measures the time takes for the server to respond to specify Vuser requests.
Rendezvous points
You insert Rendezvous points into Vuser scripts to emulate heavy user load on the
server. Rendezvous points instruct Vusers to wait during test execution for multiple
Vusers to arrive at a certain point, in order that they may simultaneously perform a
task. For example, to emulate peak load on the bank server, you can insert a
rendezvous point instructing 100 Vusers to deposit cash into their accounts at the
same time.

11
2.7 The difference between the script and the scenario:
Scripting
Scripts represent recorded user actions issued by a browser to a web application
during a web session. They are created by passing HTTP traffic through a proxy
server then encoding the recorded data, which can be edited later for use in creating
different scenarios.
Key Features
• Record and play back.
• Ability to recognize web page components (tables, links, dropdown menus,
radio buttons).
Scenario creation
Ability to determine custom load scenarios including number of Vusers, the scripts
being executed the speed of the end user connection and browser type, and the
rampup profile. In some instances, scenarios can be modified “on the fly” to create
“whatif” scenarios.
Key features:
• Vuser creation and support.
• Weighting Vusers
• Adjust Vusers access speed.
• Ability to combine scripts to create scenarios.

12
3.0 The LoadRunner Testing Process /Performance Testing Life Cycle
Planning the Test
Creating Vuser Script
Creating the Scenario
Running the Scenario
Monitoring the Scenario
Analyzing Test Results
Step I: Planning the Test

Load test planning process is a 3-step process
• Analyzing the application
• Defining the load test objectives.
• Plan Load Runner implementation.
Analyzing the application

• Identifying System Components.
• Describing the System Configuration.
• Analyzing the Usage Model.
• Task Distribution management/Licensed Agreement.
• Transaction Profile.
Defining the Load test objectives

• Stating Objectives in Measurable Terms.
• Deciding When to Test.

13
Planning LoadRunner Implementation

Defining the Scope of Performance Measurements
• Measuring end-to-end response time.
• Measuring network and server response times.
• Measuring GUI response time.
• Measuring Server response time.
• Measuring middleware-to-server response time.
Examining Load Testing Objectives

Your test plan should be based on a clearly defined testing objective.
This section presents an overview of common Load testing objectives:
• Measuring end-user response time
• Defining optimal hardware configuration
• Checking reliability
• Checking hardware or software upgrades
• Evaluating new products
• Identifying bottlenecks
• Measuring system capacity
Step II: Creating the Vuser Scripts

Vusers emulate human users interacting with your Web-based application. A Vuser
script contains the actions that each virtual user performs during scenario execution.
In each Vuser script you determine the tasks that will be:
• Performed by each Vuser
• Performed simultaneously by multiple Vusers.
• Measured as transactions
Step III: Creating the Scenario

A scenario describes the events that occur during a testing session. A scenario
includes a list of machines on which Vusers run a list of scripts that the Vusers run,
and a specified number of Vusers or Vuser groups that run during the scenario. You
create scenarios using the Load Runner Controller.

14
Creating a Manual Scenario
You create a scenario by defining Vuser groups to which you assign a quantity of
individual Vusers, Vuser scripts, and load generators to run the scripts. You can also
create a scenario using the Percentage Mode, in which you define the total number
of Vusers to be used in the scenario, and the load generator machines and
percentage of the total number of Vusers to be assigned to each Vuser script.
Creating a Goal-Oriented Scenario.
For Web tests, you can create a goal-oriented scenario, in which you define the goals
you want your test to achieve. Load Runner automatically builds a scenario for you,
based on these goals.
Step IV: Running the Scenario

You emulate user load on the server by instructing multiple Vusers to perform tasks
simultaneously. You can set the level of load by increasing and decreasing the
number of Vusers that perform tasks at the same time.
Before you run a scenario, you set the scenario configuration and scheduling. This
determines how all the load generators and Vusers behave when you run the
scenario. You can run the entire scenario, groups of Vusers (Vuser groups), or
individual Vusers. While a scenario runs, Load Runner measures and records the
transactions that you defined in each Vuser script. You can also monitor your
system’s performance online.
Step V: Monitoring a Scenario

You can monitor scenario execution using the Load Runner online run-time,
transaction, system resource, Web resource, Web server resource, Web application
server resource, database server resource, network delay, streaming media
resource, firewall server resource, ERP server resource, and Java performance
monitors.
Step VI: Analyzing Test Results

During scenario execution, Load Runner records the performance of the application
under different loads. You use Load Runner’s graphs and reports to analyze the
application’s performance.

15
3.1 Scope of Performance Measurements:

Measuring End- to- End response time:
You can run GUI or RTE Vusers at the front end to measure the response time across
the entire network, including a terminal emulator or GUI front end network and
server.
Client Middle Ware Server
Measuring the network and server response time:

You can measure the server and network response time, excluding the response time
of GUI front end, by running Vusers (Not GUI or RTE) on the client machine. Vusers
emulate client calls to the server with out user interface.
When you run many Vusers from the client, you can measure how the load affects
from network and server response time.
Measuring the GUI response time:
You can determine how the client application interface affects response time by
subtracting the previous two measurements.
GUI response time = end-to- end – network and server response time
GUI Response time

Client Middle Ware Server
Measuring server response time:

You can measure the time it takes for the server to respond a request with out going
across the network. When you run Vusers on a machine directly connected to the
server. You can measure server performance.
Measuring middleware to server response time:

You can measure response time from the server to middleware if you have access to
the middleware and it’s API. You can create Vusers with the middleware API and
measure the middleware server performance.

16
3.2 Load Testing Objectives:

Measuring end user response time:
Check how long it takes for the user to perform a business process and receive a
response from the server.
Eg: suppose that you want to verify that while your system operates under normal
load conditions, the end user receive responses to all requests with in 20 seconds.
Defining optimal hardware configuration:

Check how various system configurations (Memory, CPU, speed, cache adaptors, and
modems) affect performance. Once you understand the system architecture and
have tested the application response time, once can measure the application
response for different system configurations to determine which settings provide the
desired performance levels.
Eg: you could setup 3 different configurations and run the same tests on each
configuration to measure performance variations.
Configuration 1: 200 MHz 64 MB RAM
Checking reliability:
Determine the level of system stability under heavy or continuous workloads. You
can use load runner to create stress on the system. Force the system to handle
extended activity in a compressed time period to simulate the kind of activity a
system would normally experience over a period of weeks or months.
Checking hardware or software configuration:
Perform regressing testing to compare a new release of hardware or software to an
older release. You can check how an upgrade affects response time (benchmark) and
reliability. Application regression testing does not check new features of an upgrade;
rather it checks that the new release is an efficient and reliable as the older release.

17
Evaluating new products:
You can run tests to evaluate individual products and subsystems during the
planning and design stage of products life cycle.
Eg: you can choose the hardware for the server machine or the Database package
based on the evaluation tests.
Identifying the bottlenecks:
You can run tests that identify bottlenecks on the system and determine which
element is causing performance degradation.
Eg: File locking, resource contention, network overload, use load runner in
conjunction with the new network and machine monitoring tools to create load and
measure performance at different points in the system.
Measuring system capacity:

Measure system capacity and determine how much express capacity the system can
handle without performance degradation. To check capacity you can compare
performance vs load on the existing system and determine where significant
response time degradation begins to occur. This is often called the “Knee” of the
response time curve.
Once you determine the current capacity, you can decide if resources need to be
increased to support additional users.

18
4.0 Recording Options

This section will explain the different tabs in Recording Options and the best
practices adopted by the Performance Center.
Section 4.1:
For the Protocol and Port Mapping tabs, we are using default settings.
Section 4.2: This tab in recording options is one of the most important and decisive
ones.
Selecting a Recording Level
VuGen lets you specify what information to record and which functions to use when
generating a Load Runner script by selecting a recording level. The recording level
you select depends on your needs and environment. The available levels are HTML-
based (context sensitive) script, and URL-based script.
Follow these guidelines in deciding which recording level to choose.
• For browser applications without JavaScript, use the HTML-based level.
• For non-browser applications, use the URL-based level.
The HTML-based script level generates a separate step for each HTML user
action. The steps are also intuitive, but they do not reflect true emulation of
the JavaScript code.
The URL-based script mode option instructs VuGen to record all browser requests
and resources from the server that was sent due to the user's actions. It
automatically records every HTTP resource as URL steps (web_url statements). For
normal browser recordings, it is not recommended to use the URL-based mode since
is more prone to correlation related issues. If, however, you are recording pages
such as applets and non-browser applications, this mode is ideal. URL-based scripts
are not as intuitive as the HTML-based scripts, since all actions are recorded as
web_url steps instead of web_link, web_image, etc. In HTML recording, in order to
maintain context it looks through the previous page to make sure the current
operation is available. This adds extra overhead because it is performed by a
background utility called the runtime parser. Although the parser uses extra
overhead, it does saves us work in correlation and page checks. This because if a
link/request is not available, the runtime parser will see that and throw an error
telling us that the request is not there. (The old "Requested Form Not Found" error).

19
Therefore, HTML recording requires more memory to run as compared to the URL
mode of recording.
Best Practice at Performance Center: Since it is easier to script in HTML mode

because of the aforesaid reasons, therefore we use HTML based recording in most of
the cases. For the Advanced HTML recording options, we use the default options
shown in the following snapshot.

20
Section 4.3:
Internet Preferences Recording Options

The Internet Preference options allow the customization of code generation settings
in the area of think time, resetting contexts, saving snapshots, and the generation of
web_reg_find functions.
Record think time: (single-protocol only) Think time emulates the time that a
real user waits between actions, to influence how the Vuser uses the recorded think
time when running the script. To record user think time, select Record think time.
Reset Context for Each Action: (Web, Oracle NCA only) this setting, enabled by
default, tells VuGen to reset all HTTP contexts between actions. Resetting contexts
allows the Vuser to more accurately emulate a new user beginning a browsing
session. This option resets the HTML context, so that a contextless function is always
recorded in the beginning of the action. It also clears the cache and resets the user-
names and passwords.
Full trace recording log: (single-protocol only) This setting creates a trace log
during recording. This log is used internally by Mercury Interactive Customer Support
and is disabled by default.
Save snapshot resources locally: This option instructs VuGen to save a local copy
of the snapshot resources during record and replay. This feature lets VuGen create
snapshots more accurately and display them quicker.
Generate web_reg_find functions for page titles: (Web, Oracle NCA only)
This option enables the generation of web_reg_find functions for all HTML page titles.
VuGen adds the string from the page's title tag and uses it as an argument for
web_reg_find.
Add comment to script for HTTP errors while recording: This option adds a
comment to the script for each HTTP request error. An error request is defined as
one that generated a server response value of 400 or greater during recording

21
Best Practice at Performance Center:

“Record think time” option is checked, as think time can used later on to emulate the
time taken by real life users. “Reset Context for Each Action” option is always
checked, because of the aforesaid reasons, in the scripts. The “Full trace recording
log” is a new setting in LR 9.0 and obviously should be checked, as it might help
during correlation. “Save snapshot resources locally” is kept checked to fasten the
retrieval of snapshots during reply. “Add comment to script for HTTP errors while
recording” is a new setting in LR 8.0 and will be checked, as it helps to capture the
communication with server in detail. These setting are always open to change based
on test cases of the particular application.

22
Section 4.4:
VuGen's correlation engine allows you to automatically correlate dynamic data during
your recording session using one of the following mechanisms:
Built-in Correlation
The Built-in correlation detects and correlates dynamic data for supported application
servers. Most servers have clear syntax rules, or contexts, that they use when
creating links and referrals.
User-Defined Rule Correlation

If your application has unique rules, and you are able to determine them clearly, you
can define new rules using the Recording Options.

23

We have normally employed the rules of Manual correlation for a diverse set of
application for our client. It has been found from my experience that correlation done
by LR correlation engine often result in chaos for nothing. To provide full details on
how to manually correlate, it seems a separate document wills a better option.
Author also unsuccessfully tried to import certain correlation files (*.cor) for
automatically correlating .Net application (Consumer Malls).

24
4.5 Load Runner Recording Process

The structure and content of a Vuser script differ from one Vuser type to another.
Record a basic Vuser script
Enhance/edit the Vuser script
Configure Run-Time settings
Run the Vuser script in stand-

alone mode
Incorporate the Vuser script

into a Load Runner scenario
You begin the process of developing a Vuser script by recording a basic script. Load
Runner provides you with a number of tools for recording Vuser scripts. You enhance
the basic script by adding control-flow structures, and by inserting transactions and
rendezvous points into the script.
You then configure the run-time settings. The run-time settings include iteration, log,
and timing information, and define how the Vuser will behave when it executes the
Vuser script. To verify that the script runs correctly, you run it in stand-alone mode.
When your script runs correctly, you incorporate it into a Load Runner scenario.
4.6 Introducing VuGen

The Virtual User Generator, also known as VuGen, enables you to develop Vuser
scripts for a variety of application types and communication protocols.
VuGen not only records Vuser scripts, but also runs them. Running scripts from
VuGen is useful when debugging. It enables you to emulate how a Vuser script will
run when executed as part of a scenario.

25
When you record a Vuser script, VuGen generates various functions that define the
actions that you perform during the recording session. VuGen inserts these functions
into the VuGen editor to create a basic Vuser script.
4.7 Vuser Script Sections

Each Vuser script contains at least three sections: vuser_init, one or more Actions,
and vuser_end. Before and during recording, you can select the section of the script
into which VuGen will insert the recorded functions.
Script Section Used when recording... Is executed when...

vuser_init A login to a server The Vuser is initialized
(loaded)
Actions Client activity The Vuser is in “Running”
status
vuser_end A logoff procedure The Vuser finishes or is
stopped
When you run multiple iterations of a Vuser script, only the Actions sections
of the script are repeated—the vuser_init and vuser_end sections are not repeated.

26
4.8 Recording Web Vuser Scripts with VuGen
1. Select Start > Programs > LoadRunner > Virtual User Generator. The VuGen
main window opens.
2. Select File > New or click the New button. The New Virtual User dialog box
Opens.

27
3. Select Web (HTTP/HTML) from the All Protocols list or from the E-Business folder,
and click OK. VuGen opens a skeleton Vuser script.
4. Select Vuser > Start Recording, or click the Start recording button on the VuGen
recording toolbar. The Start Recording dialog box opens.
5. Click Options to set the recording mode, browser, proxy, and additional recording
options.
6. Type a Web site address (URL) in the URL box, or select one from the list. This is
where you will start recording the script.
7. From the Record into Action list, select the action into which you want to begin
recording, or create a new action.
To create a new action, click the New button. The Create new action dialog box
opens.
Type a name for the new action in the Action name box, or accept the default name,
and click OK. When you create a new action, VuGen adds it to the Actions list in the
skeleton Web Vuser script.
28
8. Click OK to launch the Web browser and start recording. The floating recording
toolbar appears.
9. Navigate through your Web site by clicking hypertext and hyper graphic links, and
submitting forms. Each link you click adds an Action icon to the Web Vuser script.
Each form you submit adds a Submit Form icon to the Vuser script.
10. After performing all the required user processes, click the Stop Recording button
on the floating recording toolbar. VuGen closes the browser and restores the VuGen
main window.
By default, your recorded script appears in the tree view. If your script appears in
the text-based script view, select View > Tree View to switch to the tree view.
11. Select File > Save, or click the Save button to save the Vuser script. Specify a
file name and location in the Save Test dialog box, and click Save.

29
4.9 VuGen can display a Web Vuser script in two ways:
As an icon-based representation of the Vuser script. This is the default view, and
is known as the tree view.
As a text-based representation of the Vuser script. This is known as the script
view.
To display the tree view of a Web Vuser script:

From the VuGen main menu, select View > Tree View, or click the View script as tree
icon. The Vuser script is displayed in the icon-based tree view. If you are already in
the tree view, the menu item is disabled.
The tree view of a Vuser script is composed of icons. Each icon represents an action
of the Vuser or a step in the Web Vuser script. The icons are divided into four
categories:
➤ Action Icons
➤ Control Icons
➤ Service Icons
➤ Web Check Icons

30
Action Icons
Each Action icon in the Vuser script represents a user action during recording, that
is, a jump to a new Web page or a change in the Web context.
VuGen uses five different Action icons, each one representing a different user action
during recording and playback:
URL
Link
Image
Form/Data
Submission
Custom
Request
Control Icons
Each Control icon in the Vuser script represents a control used during load testing.
Control steps include transactions, rendezvous points, and think time. You can add
control steps either while recording, or after recording.
VuGen uses these Control icons:
• Start Transaction
• End Transaction
• Rendezvous
• Think Time
Service Icons
A Service icon represents a step that does not make any changes in the Web
application context. Rather, service steps perform customization tasks such as
setting proxies, providing authorization information, and issuing customized headers.
Service steps in a Vuser script override any run-time settings that are set for the
script.
Web Check Icons

When you add a Web check during or after recording, VuGen adds a Web Check
icon to the current step in the Vuser script. Web Check icons are always indented
under the associated step.

31
4.10 Inserting Transactions
You insert transactions into a Web Vuser script to enable the Controller to measure
the performance of your Web server under various load conditions. Each transaction
measures the time that it takes for the server to respond to one or more tasks
submitted by Vusers. You can create transactions to measure simple tasks, such as
accessing a URL, or complex processes, such as submitting several queries and
waiting for a response.
To define a transaction, you insert a Start Transaction and End Transaction icon into
the Vuser script.
Within a Vuser script, you can mark an unlimited number of transactions. You insert
transaction statements into your script either while recording or after the recording
session.
During a scenario execution, the Controller measures the time it takes to perform
each transaction. After a scenario run, you use LoadRunner’s graphs and reports to
analyze the server’s performance.
Insert the Transactions

To measure the performance of the server, you define transactions. A transaction
represents an action or a set of actions that you are interested in measuring. You
define transactions within your Vuser script by enclosing the appropriate sections of
the script with start and end transaction statements. For example, you can define a
transaction that measures the time it takes for the server to process a request to
view the balance of an account and for the information to be displayed at the ATM.

32
1. Click the Start Transaction button on the VuGen toolbar. The Start Transaction
dialog box opens.
2. Type a transaction name in the Transaction Name box.

3. Click OK to accept the transaction name. VuGen inserts an
lr_start_transaction (“Transaction name”) statement in the Vuser script.
To mark the end of a transaction while recording:
1. Click the End Transaction button on the VuGen toolbar. The End Transaction dialog
box opens.
2. Click the arrow in the Transaction Name box to display a list of open transactions.
Select the transaction to close.
3. Select the transaction status from the Transaction Status list. You can manually
set the status of the transaction, or you can allow LoadRunner to detect it
automatically.
• To manually set the status, you perform a manual check within the code of
your script, evaluating the return code of a function. For the "succeed" return
code, set the status to LR_PASS. For the "fail" return code, set the status to
LR_FAIL.
• To instruct LoadRunner to automatically detect the status, specify LR_AUTO.
LoadRunner returns the detected status to the Controller.
4. Click OK to accept the transaction name and status. VuGen inserts an
lr_end_ transaction (“Transaction Name”, ”Status Of Transaction”);

33
4.11 Difference between the web_find and web_reg_find
Web_find
The web_find function searches an HTML page for a specified text string.
Syntax: (int web_find(const char *StepName, <Attributes and Specifications list>,
char *searchstring, LAST );
Eg:web_find("EmployeeCheck","expect=notfound","matchcase=yes","onfailure=abo
rt", "report=failure", "repeat=no","what=John",LAST);
web_reg_find
The web_reg_find function registers a request to search for a text string on a Web
page retrieved by the next action function, such as web_url.
Syntax
int web_reg_find(const char *attribute_list, LAST);
Eg; web_reg_find("Text=Welcome", LAST);

34
5.0 What are the logs available in virtual user generator (Vugen)
They are 4 types of logs available in virtual user generator. They are
• Replay Log
• Recording Log
• Generation Log
• Correlation Results
Replay Log
The Output window's Replay Log displays messages that describe the actions of the
Vuser as it runs. This information tells you how the script will run when executed in a
scenario, session step, or profile.
When script execution is complete, you examine the messages in the Replay Log to
see whether your script ran without errors. Various colors of text are used in the
Replay Log.
o Black: Standard output messages
o Red: Standard error messages
o Green: Literal strings that appear between quotation marks (e.g. URLs)
o Blue: Transaction Information (starting, ending, status and duration)
o Orange: The beginning and ending of iterations.
Recording Log
To view a log of the messages that were issued during recording, click the
Recording Log tab. You can set the level of detail for this log in the
Advanced tab of the Recording options.
Generation Log
To view a summary of the script's settings used for generating the code, select the
Generation Log tab. This view shows the recorder version, the recording option
values, and other additional information.
Correlation Results
Choose Vuser > Scan for Correlations or click the Find Correlations button.
VuGen scans the script for dynamic values that need to be correlated and displays
them in the Correlation Results tab.

35
6.0 Configuring Runtime Settings
After you record a vuser script, you can configure its run-time settings. The run-time
settings define the way that the script runs. These settings are stored in the file
default.cfg, located in the vuser script directory. Run-time settings are applied to
vusers when you run a script using VuGen or controller.
• Click on the Run-Time Settings button on the VuGen Tool bar.
• Press the keyboard shortcut key F4.
• Choose Vuser->Run-Time settings.
6.0.1 Configuring Run Logic in Runtime Settings

Every Vuser script contains three sections: vuser_init, Run (Actions), and vuser_end.
You can instruct a Vuser to repeat the Run section when you run the script. Each
repetition is known as iteration.
The vuser_init and vuser_end sections of a Vuser script are not repeated when you
run multiple iterations.
Number of Iterations: The number of iterations. LoadRunner repeats all of the
Actions the specified number of times.
If you specify scenario duration in the Controller's Scheduling settings, the
duration setting overrides the Vuser iteration settings. This means that if the
duration is set to five minutes (the default setting), the Vusers will continue to
run as many iterations as required in five minutes, even if the run-time settings
specify only one iteration. When you run scripts with multiple actions, you can
indicate how to execute the actions, and how the Vuser executes them:
Action Blocks: Action blocks are groups of actions within your script. You can
set the properties of each block independently—its sequence, iterations, and
weighting.
Sequence: You can set the order of actions within your script. You can also
indicate whether to perform actions sequentially or randomly.
Iterations: In addition to setting the number of iterations for the entire Run section,
you can set iterations for individual actions or action blocks. This is useful, for
example, in emulating a commercial site where you perform many queries to locate
a product, but only one purchase

36
Best Practice at Performance Center: The number of iterations will depend on

the customer’s specifications of the each individual test series. Normally, the next
iteration starts as soon as the previous iteration ends, again depending on the test
customer’s specifications.
6.0.2 Configuring Pacing in Runtime settings

Pacing Run-Time Settings
The Pacing Run-Time settings let you control the time between iterations. The pace
tells the Vuser how long to wait between iterations of your actions. You instruct the
Vusers to start each iteration using one of the following methods:
• As soon as the previous iteration ends: The new iteration begins as soon as
possible after the previous iteration ends.
• After the previous iteration ends with a fixed or random delay of ...:
Starts each new iteration a specified amount of time after the end of the previous
iteration. Specify either an exact number of seconds or a range of time. For
example, you can specify to begin a new iteration at any time between 60 and 90
seconds after the previous iteration ends. The actual amount of time that the
Vuser waits between the end of one iteration and the start of the next one
appears in the Execution Log when you run the script.
• At fixed or random intervals, every ... [to ...] seconds: You specify the time
between iteration—either a fixed number of seconds or a range of seconds from
the beginning of the previous iteration. For example, you can specify to begin a

37
new iteration every 30 seconds, or at a random rate ranging from 30 to 45
seconds from the beginning of the previous iteration. Each scheduled iteration
will only begin when the previous iteration is complete.

We normally use this option “As soon as the previous iteration ends”, which can
change according to client requirements.
6.0.3 Configuring Logs in Runtime settings
The detailed description about different option on the logging window is given as
follows:
Enable Logging
This option enables automatic logging during replay—VuGen writes log messages
that you can view in the Execution log.
38
Log Options
The Log run-time settings allow you to adjust the logging level depending on your
development stage. You can indicate when to send log messages to the log: Send
messages only when an error occurs or Always send messages. During development,
you can enable all logging. Once you debug your script and verify that it is
functional, you can enable logging for errors only.
Setting the Log Detail Level
You can specify the type of information that is logged, or you can disable logging
altogether, which is done when we are running scripts in the controller as it results
unnecessary usage of system resources and can skew the performance results.
Standard Log: Creates a standard log of functions and messages sent during script
execution to use for debugging. Disable this option for large load testing scenarios.
Extended Log: Creates an extended log, including warnings and other messages.
Disable this option for large load testing scenarios. If logging is disabled or if the
level is set to Extended, adding it to a scenario does not affect the log settings.
You can specify which additional information should be added to the extended log
using the Extended log options:
• Parameter substitution: Select this option to log all parameters assigned to the
script along with their values.
• Data returned by server: Select this option to log all of the data returned by the
server.
• Advanced trace: Select this option to log all of the functions and messages sent
by the Vuser during the session. This option is useful when you debug a Vuser
script.

As it has been mentioned in the description above that generally, we check all the
three logging options if and when we are correlating & parameterizing the scripts.
This gives us all the details of communication with the server. But, while running the
scripts in the scenario, disable the “Enable logging” checkbox unless it becomes
necessary to see the details again, because otherwise it will waste harddisk space
and memory of the load generators, which can skew our load testing results. We
check “Send Messages only when an Error” option as this helps to troubleshoot if
there is some problem while running the scenario.

39
6.0.4 Configuring Think Time in Runtime settings
Vuser think time emulates the time that a real user waits between actions.
For eg:- when a user receives data from a server, the user may wait several
seconds to review the data before responding. This delay is known as think time.
VuGen uses lr_think_time functions to record think time values into your Vuser
scripts.
Transactions / hour = no. of user* 60 /
(Action section Execution time + Think time + Pacing Time)
The description about different options on Think Time window is as follows:

Ignore think time: Ignore the recorded think time—replay the script ignoring all
lr_think_time functions.
Replay the think time: The second set of think times options let you use the
recorded think time:
• As recorded: During replay, use the argument that appears in the lr_think_time
function. For example, lr_think_time(10) waits ten seconds.
• Multiply recorded think time by: During replay, use a multiple of the recorded
think time. This can increase or decrease the think time applied during playback.
For example, if a think time of four seconds was recorded, you can instruct your
Vuser to multiply that value by two, for a total of eight seconds. To reduce the
think time to two seconds, multiply the recorded time by 0.5.
• Use random percentage of the recorded think time: Use a random
percentage of the recorded think time. You set a range for the think time value
by specifying a range for the think time. For example, if the think time argument

40
is 4, and you specify a minimum of 50% and a maximum of 150%, the lowest
think time can be two (50%) and the highest value six (150%). This can be said
to be the best way of putting think time in the scripts because even in the real
world, not two people will fill any particular form in same time.
• Limit think time to: Limit the think time's maximum value.

In all of our scenarios, we choose to ignore the Think Time. The reason behind this is
that we do not have a reliable and accurate way to measure think time in our
production environment and there fore would be skewing our test results by
guessing at the Think Time. On some occasions, based on customer’s test
specifications, we may use Think Time to slow our transactions in the scenario. This
is usually done during a duration type test when the normal pace of our transactions
is very fast and we need to extend that duration for the purpose of achieving the test
goals. Author believes that it would be best to go by “Use random percentage of the
recorded think time” option. It would help us in emulating the real life scenario
because no two people in this world will do any activity in same time. Sometimes it is
good to go into the script and modify recorded think times (say to make them all x
seconds) and add think times to proper places where they are missed to ensure a
fixed, controlled wait between every user action.
6.0.5 Configuring Miscellaneous Runtime Settings

We can set the following general run-time options for a vuser script:

41
• Error handling
• Multithreading
• Automatic Transactions
Error Handling
Continue on Error: This setting instructs Vusers to continue script execution when
an error occurs. This option is disabled by default.
Fail open transactions on lr_error_message: This option instructs VuGen to
mark all transactions in which an lr_error_message function was issued, as Failed.
Generate Snapshot on Error: This option generates a snapshot when an error
occurs. You can see the snapshot by viewing the Vuser Log and double clicking on
the line at which the error occurred.
Multithreading
The primary advantage of a multithread environment is the ability to run more
Vusers per load generator. Only threadsafe protocols should be run as threads.
The Controller uses a driver program (e.g., mdrv.exe, and r3vuser.exe) to run
your Vusers. If you run each Vuser as a process, then the same driver program is
launched (and loaded) into the memory again and again for every instance of the
Vuser. Loading the same driver program into memory uses up large amounts of
RAM (random access memory) and other system resources. This limits the
numbers of Vusers that can be run on any load generator. Alternatively, if you
run each Vuser as a thread, the Controller launches only one instance of the
driver program (e.g., mdrv.exe), for every 50 Vusers (by default). This driver
process/program launches several Vusers, each Vuser running as a thread. These
threaded Vusers share segments of the memory of the parent driver process.
This eliminates the need for multiple re-loading of the driver program/process
saves much memory space, thereby enabling more Vusers to be run on a single
load generator.
Automatic Transactions
You can instruct LoadRunner to handle every step or action in a Vuser script as a
transaction. This is called using automatic transactions. LoadRunner assigns the
step or action name as the name of the transaction. By default, automatic
transactions per action are enabled.

42
• To disable automatic transactions per action, clear the Define each action as a
transaction check box. (enabled by default)
• To enable automatic transactions per step, check the Define each step as a
transaction check box. (disabled by default)

1) In the Miscellaneous settings, the Error Handling is left unchecked.
2) Due to limited hardware and time, mostly we use Vusers as threads.
3) In most cases, we are measuring both the action and each step. This additional
data helps us to analyze the transactions and identify the slowest pieces of the
application, as this is where we would start to focus on enhancing the performance of
the application. Normally we also insert transactions manually into the script, which
will give us the timings of any particular transaction. To set proper order of the
timings of the transactions, we normally prefix the transaction name by numbers like
01, 02, 03 etc. This naming has helped us to analyze the timings of different
components of the application more efficiently. Please DO NOT include think time
and, output messages or any other custom program logic in the start and end
transaction.
4) “Generate Snapshot on Error” option will be checked in future. This will be very
useful when there are errors and you want to see or share how the error pages look.
6.0.6 Configuring Bandwidth Runtime Settings

Using the Speed Simulation settings, you can select a bandwidth that best emulates
the environment under test. The following options are available:
Use maximum bandwidth

By default, bandwidth emulation is disabled and the Vusers run at the maximum
bandwidth that is available over the network.

43
Use bandwidth
Indicate a specific bandwidth level for your Vuser to emulate. You can select a speed
ranging from 14.4 to 512 Kbps, emulating analog modems, ISDN, or DSL.
Use custom bandwidth
Indicate a bandwidth limit for your Vuser to emulate. Specify the bandwidth in bits,
where 1 Kilobit=1024 bits.
Since most of our customers use the high speed Internet, we normally use the option
of “Use Maximum bandwidth”. It might be another challenge to load test the
application at low internet speeds.
6.0.7 Configuring Browser Emulation

Setting Browser Emulation Properties
• Simulate browser cache: This option instructs the Vuser to simulate a
browser with a cache. A cache is used to keep local copies of frequently
accessed documents and thereby reduces the time connected to the network.
By default, cache simulation is enabled. When the cache is disabled,
LoadRunner still downloads each page image only once. When running
multiple Vusers from the Controller, every Vuser uses its own cache and
retrieves images from the cache. If you disable this option, all Vusers emulate
a browser with no cache available. You can also set the following two browser
cache options:
• Cache URLs requiring content (HTML): This option instructs VuGen to
cache only the URLs that require the HTML content. The content may be
necessary for parsing, verification, or correlation. When you select this option,
HTML content is automatically cached. This option is enabled by default.
• Check for newer versions of stored pages every visit to the page: This
setting instructs the browser to check for later versions of the specified URL,
than those stored in the cache. When you enable this option, VuGen adds the
"If-modified-since" attribute to the HTTP header. This option guarantees that
the most recent version of the page always appears, but generates more
traffic during scenario execution. By default, browsers do not check for newer
resources, and therefore this option is disabled.
• Download non-HTML resources: This option instructs Vusers to load
graphic images when accessing a Web page during replay. This includes both

44
graphic images that were recorded with the page, and those, which were not
explicitly recorded along with the page. When real users access a Web page,
they wait for the images to load. Therefore, enable this option if you are
trying to test the entire system, including end-user time (enabled by default).
To increase performance and not emulate real users, disable this option.
• Simulate a new user each iteration: Instructs VuGen to reset all HTTP
contexts between iterations to their states at the end of the init section. This
setting allows the Vuser to more accurately emulate a new user beginning a
browsing session. It deletes all cookies, closes all TCP connections (including
keep-alive), clears the emulated browser's cache, resets the HTML frame
hierarchy (frame numbering will begin from 1) and clears the user-names and
passwords. This option is enabled by default.
• Clear cache on each iteration: Clears the browser cache for each iteration
in order to simulate a user visiting a Web page for the first time. Clear the
check box to disable this option and allow Vusers to use the information
stored in the browser's cache, simulating a user who recently visited the
page.

We check the option “Simulate Browser Cache”, which helps to emulate the cache for
browser. We check “Simulate a new user each iteration” as we normally record user
login, logout, and transaction all in the Action section of the script AND we want to
simulate new users between iterations. This will reset the context (such as cookies)
during the script playback between iterations

45
We also check following options:
• “Download non-HTML resources”
• “Clear cache on each iteration”.
As it has been already explained about the above 2 points that these help to emulate
a real life user, therefore we use check these options to emulate real life load on the
applications
6.0.8 Configuring Internet Protocol Runtime Settings Proxy
Proxy runtime settings are used to provide the Proxy server details to the scripts.
By default, the Vuser uses the proxy settings of the browser used for recording in the
Web recording options. It is recommended that you use the same settings for record
and replay.
The following proxy options are available in the Run-Time settings.
• No proxy: All Vusers always use direct connections to the Internet. This means
that the connection is made without using a proxy server.
• Obtain the proxy settings from the default browser: All Vusers use the
proxy settings of the default browser from the machine upon which they are
running.
Use custom proxy: All Vusers use a custom proxy server. You can supply the actual
proxy server details or the path of a proxy automatic configuration script (.pac file)
that enables automatic configuration. To supply the details of the server, you specify
its IP address or name and port. You can specify one proxy server for all HTTP sites,
and another proxy server for all HTTPS (secure) sites.

46
Author has also observed that some of the companies use proxy servers to get
connected to the server due to security reasons, therefore it is best to use “Obtain
the proxy settings from the default browser” option.
Preferences
Image and Text Checks
The Enable image and text checks option allows the Vuser to perform verification
checks during replay by executing the verification functions: web_find or
web_image_check. This option only applies to statements recorded in HTML-based
mode. Vusers running with verification checks use more memory than Vusers who do
not perform checks (disabled by default).
Generating Web Performance Graphs

Instructs a Vuser to collect data used to create Web Performance graphs. You view
the Hits per Second, Pages per Second, and Response Bytes per Second
(Throughput) graphs during test execution using the online monitors and after test
execution using the Analysis. You view the Component Breakdown graph after test
execution using the Analysis.

47
Advanced Web run-time options
File and line in automatic transaction names: Creates unique transaction names
for automatic transactions by adding file name and line number to the transaction
name (enabled by default).
This option places additional information in the log file, and therefore requires more
memory.
Non-critical item errors as warnings: This option returns a warning status for a
function which failed on an item that is not critical for load testing, such as an image
or Java applet that failed to download. This option is enabled by default. If you want
a certain warning to be considered an error and fail your test, you can disable this
option.
Save a local copy of all snapshot resources during replay: Instructs VuGen to
save the snapshot resources to files on the local machine. This feature lets the Run-
Time viewer create snapshots more accurately and display them quicker.

48

• The “Checks” have been left unselected, as normally we do not have any checks
in our scripts unless specified by customer.
• “Hits per second and HTTP codes” and “Response bytes per second” options are
checked, which help us to do better analysis.
• In the Advanced tab, we have checked the following three options:
1) “File and line in automatic transaction names”, because it helps to give each
transaction name uniquely, which helps us in analysis to avoid any confusion.
2) “Non-critical item errors as warnings”: This avoids the failure of tests due to
unimportant items.
3) “Save a local copy of all snapshot resources during replay”: This helps to run
tests fast as the snapshots are stored locally.
Additional Options for Internet Preferences
DNS caching: Instructs the Vuser to save a host's IP addresses to a cache after
resolving its value from the Domain Name Server. This saves time in subsequent
calls to the same server. In situations where the IP address changes, as with
certain load balancing techniques, be sure to disable this option to prevent Vuser
from using the value in the cache. (enabled by default)
HTTP version: Specifies which version HTTP to use: version 1.0 or 1.1. This
information is included in the HTTP request header whenever a Vuser sends a
request to a Web server. The default is HTTP 1.1..
Keep-Alive HTTP connections: Keep-alive is a term used for an HTTP
extension that allows persistent or continuous connections. These long-lived HTTP
sessions allow multiple requests to be sent over the same TCP connection. This
improves the performance of the Web server and clients.
The keep-alive option works only with Web servers that support keep-alive
connections. This setting specifies that all Vusers that run the Vuser script have
keep-alive HTTP connections enabled. (Yes by default)
Step timeout caused by resources is a warning: Issues a warning instead of
an error when a timeout occurs due to a resource that did not load within the
timeout interval. For non-resources, VuGen always issues an error. (No by
default)

49
Parse HTML content-type: When expecting HTML, parse the response only
when it is the specified content-type: HTML, text\html, TEXT any text, or ANY,
any content-type. Note that text/xml is not parsed as HTML. The default is TEXT.
Accept-Language request header: Provides a comma-separated list of
accepted languages. For example, en-us, fr, and so forth.
HTTP-request Receive/Connect Timeout (seconds): The time, in seconds,
that a Vuser will wait for the connection of a specific HTTP request within a step
before aborting. Timeouts provide an opportunity for the server to stabilize and
respond to the user. The default value is 120 seconds. The timeout settings are
primarily for advanced users who have determined that acceptable timeout
values should be different for their environment. The default settings should be
sufficient in most cases. If the server does not respond in a reasonable amount of
time, check for other connection-related issues, rather than setting a very long
timeout, which could cause the scripts to wait unnecessarily.
Step download timeout (seconds): The time that the Vuser will wait before
aborting a step in the script. This option can be used to emulate a user behavior
of not waiting for more than x seconds for a page.
Network Buffer Size: Sets the maximum size of the buffer used to receive the
HTTP response. If the size of the data is larger than the specified size, the server
will send the data in chunks, increasing the overhead of the system. When
running multiple Vusers from the Controller, every Vuser uses its own network
buffer

50
• “DNS Caching” is given value “Yes”.
• “Keep-Alive HTTP Connections” is given value “Yes”.
• We have kept the timeout for step download as 120 seconds because if we can’t
download something in 120sec(2min), then it definitely needs to be tuned to give
better performance. Anyhow in case of any special case, we can set the
maximum values of these timeouts as follows:
1) Connect/Receive timeout -> 1000 seconds
2) Step download timeout -> 32000 seconds
Please refer to go to mercury support site (http://support.mercury.com) for more
doubts and refer to these four threads: 15450, 11299, 22864, and 15370.
It may be kept in mind that some people have found problems while using non-us
settings, so just watch out when you these settings.

51
7.0 General Options

This section will explain about details of different tabs in General Options and the
best practices adopted by the HTSC Farmington Performance Center.
Section 7.1: Playback in VuGen

When a script is played back in VuGen, a runtime viewer can be invoked to display
the responses coming back from the server. By checking the “Auto Arrange window”,
it helps us to arrange different window in the proper places.
However, it is should be kept in mind that runtime viewer is only a simulated

browser and does not full capabilities of browser. In other words, the display on the
viewer may sometimes be different from what one would expect from an actual
browser. At times a “script error” window may pop up. This does not mean the script
is incorrect, and the most secure way to verify the script is to turn on logging and
examine the execution log. You can run your script without the runtime view
enabled. As a matter of fact, if your page has a lot of Java Scripts, it is
recommended that you playback the script with the Runtime Viewer disabled. Please
refer to go to mercury support site (http://support.mercury.com) for more doubts
and refer to these four threads: 14094, 17234, 16973, and 3934.

52
8. 0 Enhancing Scripts in VUGen
Parameterizing the script
VuGen generates a script that contains the actual values used during recording.
Suppose you want to perform the script’s action using different values from those
recorded. To do this, you replace the recorded values with parameters. This is known
as parameterizing the script. or
When we enter certain values during recording the application, this will get hard-
coded in the script. But to truly test the application, we need to iterate a script
number of times, which requires parameterization.
8.1 Advantages of the Vuser script.

• It reduces the size of the script.
• It provides the ability to test your script with different values.
8.2 Parameterization involves 2 tasks

• Replacing the constant values with the Vuser script with parameters.
• Setting the properties and data source for the parameters.
8.3 Steps to perform Parameterization

• Select the value which u need to parameterize and right click the mouse
• Select replace with a parameter option
• Following screen will be displayed.
• Enter the value for the parameter name
• Click on OK.

53
8.4 Defining Parameter Properties
• Right Click the parameter and right click pop-up opens.
• From the Pop-up menu, select parameter properties. The parameter
properties dialog box opens and displays the properties that are relevant for
the current parameter type.
• Change the Properties accordingly and click on Close.
Sequential: each VUser (in a multi-user scenario) will traverse the whole list
individually.
Random: the value will be randomly chosen.
Unique: all users will traverse the list together and a unique value (row) is assigned
to each VUser (unless the list is exhausted).
8.5 Parameter types
• Date/Time
• File
• Group Name
• Iteration Number
• Load Generator Name
• Random Number
• Table
• Unique Number
• User Defined Function
• Vuser ID

54
Same line as <some-other-parameter>: the parameter is “anchored” to <some-

other-parameter>.
We should be cautious while working with big data files in Notepad, as columns do
not automatically line up. It is better to save parameter files as ‘tab delimited’ files
and then opening the file in Excel to edit and maintain it. When you are done
modifying with the file, save it as 'Text (tab delimited)' and overwrite the script’s
DAT file. Please refer to go to mercury support site (http://support.mercury.com) for
more doubts and refer to these threads:
23501, 23416, 15494, 15318,15821, 12725, 19703,12747 and 18876

55
9.0 Correlation
It is used for capture the dynamic value for a particular field at run time is known as
correlation. Or Capturing the dynamic value at server response is known as
correlation.
Correlation is where the script is modified so that some of the hard-coded values in
the script are no longer hard-coded. Rather then sending the original value to the
server, we may need to send different values.
For example, the original recorded script may have included the server sending the
client a session identification number, something to identify the client during that
particular session. This Session ID was hard-coded into the script during recording.
During replay, the server will send the client a new Session ID. You need to capture
this value, and incorporate it into the script so you can send it back to the server to
correctly identify yourself for this new session. If you leave the script unmodified,
you will send the old hard-coded Session ID to the server. The server will look at it
and think it invalid or unknown, and so will not send the pages that have been
requested. Replaying a script with an old Session ID will not successfully fool the
server into believing it is a client.
Correlation is the capturing of dynamic values passed from the server to the client
and back. You save this captured value into a parameter, and then use this
parameter in the script in place of the original value. During replay, the replay
engine will now listen to what the server sends to it, and when it makes requests of
the server, send this new, valid value back to the server; thus fooling the server into
believing it is talking to a real client.
9.1 Purpose of Correlation

The primary reason for correlating statement is
• To simplify or optimize your code
• For Dynamic Data
• To accommodate unique records.
You can also enhance the scripts by
• Inserting transactions into a Vuser script.
• Inserting Rendezvous point into a Vuser script
• Inserting comments into the script.
• Sending messages output.
• Handling errors in Vuser Scripts

56
9.2 Why do I have to correlate?
If you try to replay a script without correlating first, the script will most likely fail.
The server will not reply to the requests it sends. Either the Session ID is invalid so
the server will not allow you into the site, or it will not allow you to create new
Records because they are the same as existing ones, or the server will not
understand your request because it is not what it is expecting.
The following diagram illustrates a typical example where correlation is required.
While recording, the client request for page A with the ID “123.” This information
(123) will be intercepted by the Web recorder and placed as a hard-coded value in
the script. During replay, even though the ID is supposed to be “456,” the Web
Vuser sends “123” to the server causing a replay failure. You will need to correlate
this value so that the correct data is sent to the server.
As a rule of thumb, any value that changes every time you connect to the server
is a candidate for correlation. A correlated script will send the server the

57
information it is looking for thus allowing the script to replay. This will allow
many Vusers to replay the script many times, placing load on your server.
9.3 What errors mean I have to correlate?

There are no specific errors that are associated with correlation, but there are errors
that could occur because a value has not been correlated. For example, if an invalid
Session ID is sent to a Web server, how that server responds depends on the
implementation of that server.
It might send a page specifically stating the Session ID is invalid and ask you to log
in again. It might send an HTTP 404 Page not found error because the requesting
user did not have permissions for the specified page, and so the server could not find
the page.
In general, any error message returned from the server after the script makes a
request that complains about permissions can point to a hard-coded value that needs
to be correlated.

58
9.4 How to Correlate a Web Script
Functions For Correlation
Function Description
web_reg_save_param This is the latest function with some extra features for
a more powerful usage. The syntax is as following:
web_reg_save_param ( “Parameter Name” , <List of
Attributes>, LAST );
Each of these parameters is a pointer to a string. That
means that if they are entered as literal text, they
need to be enclosed in quotes, with each parameter
separated by a comma. The supported attributes
include LB (Left boundary), RB (Right boundary),
RelFrameID, ORD, Search, SaveOffset, SaveLen, and
Convert. These attributes can appear in any order
because they contain within them what they are.
Detail information about each attribute can be found
on the function reference online.
Web_create_html_param Both of these functions are for backward compatibility

only. It is recommended that you use the
web_reg_save_param function. If you need to use this
Web_create_html_param_ex
function for some reason, please refer to the function
help reference.
A list of all the three functions, along with documentation and examples, can be
found in the on-line documentation. From VuGen, go to Help → Function reference →
Contents → Web and Wireless Vuser Functions → Correlation Functions.

59
9.5 How to identify values to correlate
What values in the script need to be correlated? The simplest answer is “Any value
that changes between sessions required for the script to replay.”
A hypothetical example
You are logging onto a website. When you send the server your user name and
password, it replies with a Session ID that is good for that session. The Session ID
needs to be correlated for replay. You need to capture this value during replay to
use in the script in place of the hard-coded value.
There are two easy ways to identify the values and to correlate:
1. Correlation with the auto correlation engine, and
2. Manually correlation.

60
9.6 Correlation with the auto-correlation engine
VuGen’s auto-correlation engine allows you to automatically correlate dynamic data
using the following methods:
Correlation Description
mechanism
Rules Rules Correlation operates during recording. There are two types of
Correlation Rules correlation:
• Built-in Correlation
The Built-in Correlation detects and correlates dynamic data for
supported application servers. If you are recording a session with a
supported application server, you can use one of the existing rules. An
application server may have more than one rule. You can enable or
disable a specific rule by selecting or clearing the checkbox adjacent to
the rule. VuGen displays the rule definitions in the right pane.
• User-defined Rules Correlation
User-defined Rules Correlation allows you to define your own
correlation rules before you record a session. The rules include
information such as the boundaries of the dynamic data you want to
correlate and other specifications about the match such as binary, case
matching, and the instance number.
Correlation Correlation Studio operates after replay, which means that you need to
Studio run the script at least once. After replay, the studio automatically tries
to find matching values from the server’s responses and the client’s
request, and estimates the need for correlation. The studio is usually
used to initially find places to correlate, in unfamiliar environments.

61
9.6.1 Rules Correlation (Record)
To record with the Rules Correlation mechanism, follow the steps below.
1. Enable auto-correlation.
a. Enable the auto-correlation option in VuGen’s Tools menu, under Recording
options → Internet Protocol: Correlation. Click on “Enable correlation during
recording” to turn on the feature.
b. (Built-in Correlation) Indicate the servers to which you want to apply the
correlation rules. Select the checkboxes adjacent to the server names to
enable the rules for that server. To enable specific rules within a server
group, click the plus sign to expand the tree and select the desired rules.
c. (User-define rule correlation) To add a new rule to an existing server,
select one of the existing entries and click “New Rule.” Set the properties for
the rule in the right pane.
d. Set the option on how you want the recorder to behave when there is a
dynamic value matching the rule being detected. The available options are
• Issue a pop-up message and let me decide online (Tips: Correlation
warning window on recording)
• Perform correlation in script
2. Record a script.
Start a recording. The Web recorder will automatically correlate the dynamic
values that match the correlation rule defined on step 1. After the recording,
assuming there are dynamic values being detected and correlated, you will see
something similar to the following in your script:

62
3. This is all regarding correlation rules. Replay the script as desired
9.6.2 Correlation Studio (Replay)

Very often, you will notice that not all the dynamic values are correlated with the use
of Rules Correlation. This is likely to happen when you are recording against a
session on an unsupported application server whose context is not known, and you
cannot determine any correlation rules.
To handle this, the Web protocol comes with the Correlation Studio, where after
running the script, it will automatically compare the server’s response for record and
replay, to look for dynamic values for correlation. The list of differences will be
reported to you, for you to choose the ones to correlate.
To invoke this feature,
1. Run the script once.
2. After the run, you will see the following pop-up alert prompting for “Scan Action
for correlation.” Click on “Yes” to start the scan.

63
Tips: Scan Action for Correlation window does not come up after replay
Tips: How to manually start the ‘Scan Action for Correlation’ feature
3. During the scan, the Correlation Studio will automatically compare the record and
replay response for dynamic values and report the differences to you. You can
see the dynamic values that are detected on the lower panel, under the
“Correlation Results” tab.
4. Look through the differences reported by the Correlation Studio. Correlate the
values on those necessary. To make the correlation process easy, you can
choose the option to correlate them either one at a time (Correlate) or all at once
(Correlate All).
Note: Correlation Studio often reports all the dynamic values, including those
where you do not need to correlate. Because of this, Mercury recommends you to
use the Correlate option, and look at the value to correlate one at a time.
When you correlate a value using this mechanism, VuGen inserts a
web_reg_save_param function and a comment into your script indicating that
a correlation was done for the parameter. It also indicates the original value.

64
5. In general, you will need to repeat steps 1-4 a few times, before you can
correlate all the dynamic values. The Correlation Studio is not likely to report all
the differences with just one run because your script is prone to fail on a very
early stage. This causes the subsequent dynamic values to go undetected.
Example:
Your business process includes the following:
1. Log onto the site.
2. Retrieve employee information.
3. Update employee information.
4. Logout.
If the logon process (step 1) fails on the first run and halts the replay, step 2 and
above of the example will not be executed. For such, the Correlation Studio will
NOT be able to report the dynamic values of step 2 and above. To handle this
case, what you will need to do is to repeat the correlation processes. The steps
needed are similar to the following:
1. Run the script once.
2. Identify and correlate the values needed to allow logon process.
3. Rerun the script.
4. Identify and correlate the values needed to retrieve employee information.
5. Run the script again.
6. Identify and correlate the values needed to update employee information.
There are cases where the Correlation Studio may not detect some dynamic values.
You may need to perform manual correlation as guided on the following chapter.
Tips: Why does Correlation Studio fail to detect all the dynamic values.
9.7 Steps to Perform Manual Correlation

1. Record two copies of the script with the same business process and data:
a. Record a script on the desired business process and save it.
b. Record another copy of the script, repeating all the steps as in step 1a. As
much as possible, during recording, enter the same values in both scripts, for
example, user ID, password, and fields and edit selections.

65
2. Identify the values to correlate with the help of the WinDiff tool:
a. From the second script, go to Tools → Compare with Vuser, and choose the
first recorded script.
b. WinDiff will open and display the two scripts side by side. It will automatically
highlight the lines with differences in them, showing the differences in red. (If
not, go to Options → View → Show inline differences.)
Tips: Error: "File no longer available." launching WinDiff
c. Locate the first difference, take note of it, and search the script open in
VuGen for that difference. That is the original value hard-coded into the
script that was different in the second script. Highlight it and copy it.
Note: Differences like "lr_think_time" can be ignored. They are pacing functions,
and do not represent data sent to the server.
d. Go to the Recording Log (for Single Protocol) or Generation Log (for Multiple
Protocol) and place your cursor at the top. Press Control-F (CTRL+F) to bring
up the Find window.

66
• Paste the value copied from step 2c and search downward. You are looking
for the first occurrence of this value in the Recording Log or Generation Log.
• If you do not find the value, verify you are looking in the correct script’s
Recording Log or Generation Log. Remember you have two almost identical
scripts here.
• If you find the value, scroll up in the log, and make sure the value was sent
as part of a response from the server. The first header you come across
while looking up the script should be prefaced by a receiving response. This
indicates that the server sent the value to the client. If the value first
appears as part of a sending request, then the value originated on the client
side and does not need to be correlated, but rather parameterized. That is a
different topic all together. The response will have a comment before it that
looks like this:

67
e. So, you have a value that is different between subsequent recordings, it was
sent from the server to the client; this value most likely needs to be
correlated. If the value is not different between recordings and not
originating on the server and sent to the client then the value probably does
not need to be correlated.
3. Manually correlate the script with the web_reg_save_param function.

After confirming that the first occurrence was part of a received response from
the server, you need to figure out where to place the web_reg_save_param()
function and what to put in it before creating the function
a. Where to place the web_reg_save_param function?
From the last step, you located the dynamic value inside the Execution Log.
Pick up the text that is before the dynamic value. This text should remain
constant no matter how many times you replay the script; highlight it and
copy it. This is the text that will identify where to find the start of the value
you are capturing.
Now, to identify the place to put the function, you need to replay the script once in
extended log. To do this,
• Go to the Vuser menu and select “Run-Time Settings.”
• Go to General Log
• Select “Enable Logging,” “Always sends messages,” “Extended log,” and all
the options under extended log.

68
After replay, go to the Execution Log and search for the text that you just copied
from the Recording Log (for Single Protocol) or Generation Log (for Multiple
Protocol). You should see a corresponding Action1.c() at the beginning of that line
with a number in the brackets. That is the number of the line in the script where you
need to put web_reg_save_param( ) function. The function should go right above
that line in the script.
So, add a couple of blank lines to your script before the function at that line, and
then type in web_reg_save_param (“UserSession”, but give it a name that means
more to you than UserSession.
b. Identifying the boundaries for web_reg_save_param function.
• Identifying the left boundary - The starting point to correlate.

Go back to the Recording Log (for Single Protocol) or Generation Log (for Multiple
Protocol), highlight the text to the left of the dynamic value and copy it.
The amount of text you highlight should be sufficient so that it is unique in this reply
from the server. It is suggested that you copy as much as possible without copying
any special characters. This is shown in the Execution Log as black squares, and the
actual character they represent is uncertain. After selecting a boundary, go to the
top of the Servers reply, and press CTRL+F and do a search for that boundary. You

69
want to make certain what you have selected is the first occurrence in the Servers
reply. If it is not select, use more text to make it unique, or consider using the ORD
parameter of the web_reg_save_param function. Once you have finalized the static
text that represents the left boundary, copy it into the web_reg_save_param
statement.
Tips: How to handle special characters ( \r \n \t " ) when correlating script
The function you will have so far would be

web_reg_save_param(“UserSession”, “LB=input type=hidden name=userSession
value=”,
i. Identifying the right boundary - The ending point to correlate.
You are now going to tell the replay engine how to identify the end of the value you
are trying to capture, that is, the right boundary of what you are looking for. Again,
look in the Execution Log and copy the static text that appears to the right of the
dynamic value you are looking for. For example, let’s say the Execution Log
contained the following:
… userSession value=75893.0884568651DQADHfApHDHfcDtccpfAttcf>…
Then, the example so far to save the number into the parameter UserSession would
be
web_reg_save_param(“UserSession”, “LB=input type=hidden
name=userSession value=”, “RB=>”,LAST);

70
Note: In choosing a right boundary, make sure you choose enough static text to
specify the end of the value. If the boundary you specify appears in the value that
you are trying to capture, then you will not capture the whole value.
4. Replace the hard-coded value in the script with the parameter.

Once you have created the parameter, the next step is to replace the hard-coded
occurrences with the parameter. Look through the script for the original value.
Where you find it, delete the value and replace it with the parameter. Note, only
the value you want replaced is deleted. The characters around it remain.
Example:
Change:
"Name=userSession", "Value=75893.0884568651DQADHfApHDHfcDtccpfAttcf", ,
To: "Name=userSession", "Value= {UserSession}", ENDITEM,

71
At this point, you are ready to run the script to test if it works, or if it needs further
correlation, more work on this correlation.
5. Recap
That was a lot of looking through the logs and checking of values. Let’s just recap
what you have done. You have identified a value that you think needs to be
correlated. You then identified in the script where to place the statement that would
ultimately capture and save the value into a parameter. You then placed the
statement, and gave the text strings that appear on either side of the value that you
are looking for so that it can be found.
The flow of logic for this is the correlation functions tell the replay engine, what to
look for in the next set of replies from the server. The replay engine makes a
request of the server. The server replies. The replay engine looks thorough the
replies for the left and right boundaries. If it finds them, what is in-between is then
saved to a parameter of the name specified.
Remember, the parameter cannot have a value until after the next statement is
executed. The correlation statement only tells the replay what to look for; it does
not assign a value to the parameter. Assignment of a value to the parameter does
not happen until after generating request to the server and looks in the reply. If you

72
have a case where a correlation statement is followed by a function that attempts to
use the parameter, the statement is in the wrong place, and the script will fail.
This is always incorrect:
web_reg_save_param(…);
Web_submit_data (… {Parameter}…);
In-between the two, there needs to be a request of the server that causes it to reply
with the value you are trying to capture.
When you are done with the above, the next step is to replace the hard-coded
occurrences with the parameter. The script is then ready for replay.
9.8 Tips and Tricks

How to print out the parameter value
Sometimes you want to print out the value that was assigned to a parameter. To do
this, use the lr_eval_string function and the lr_output_message function. For
example, to print the value of the parameter to the Execution Log:
lr_output_message(“ Value Captured = %s",
lr_eval_string("{ParameterName}"));
If you find that the value being substituted is too long, too short, or completely
wrong, printing out the value will help identify the changes you need to make to the
correlation function.
9.9 How to handle special characters (\r \n \t “) when correlating script

There are some special characters and cases when specifying the boundaries.
Special characters (e.g., '\', '"\) in the boundaries must be "escaped" by a backslash.
Example:
Recording Log (for Single Protocol),

or Generation Log (for Multiple Left boundary Right boundary
Protocol)
Value="57685" "Value=\"" "\""
"Value_\"\\item\\\"value’
Value_"\item\"value’7875’ "’"
"
Value=
"Value=\r\n\"" "\""
"7898756"

73
9.10 Cannot find the recording snapshot under the script’s data directory
If there is no recording snapshot displayed for the selected step, check the following
possible reasons:
• The script was recorded with a VuGen version 6.02 or earlier.
• The imported Actions do not contain snapshots.
• The Vuser files are stored in a read-only directory, and VuGen could not save the
replay snapshots.
• Snapshots are not generated for certain types of steps. For example, a snapshot
will not be generated if the step represents navigation to a resource.
• The following option was turned off to disable snapshot generation:
Tools → General options → Correlation tab → Save correlation information during
replay.
9.11 Error: "File no longer available" when launching the WinDiff tool
The Compare tool in VuGen makes use of a standard utility called WinDiff. WinDiff
has certain limitations, in that it cannot handle directories and files with spaces. To
resolve the issue, move the script directory to a new drive without any spaces, and
try to keep the names short. Alternatively, open WinDiff manually, and open up the
scripts via the menu options. Simply compare the action1.c sections of the scripts in
question.
9.12 Error: “No match found for the requested parameter 'ParameterName'.
If the data you want to save exceeds xx bytes, use
web_set_max_html_param_len to increase the parameter size."
By default, the web_reg_save_param function issues the above error if the
boundaries cannot be found. If you need to use this function for other purposes, and
would like to avoid errors, use the "Notfound=warning" attribute so that the
replay will just issue a warning.
Now, the above error actually suggested two possible causes for the error,
1. The boundaries defined cannot be found, and
2. The data you want to save exceeds 256 bytes.
The advice given is just a recommendation that you must take into consideration.
Was the value you were trying to capture more than 256 characters long? In the
above example, it was only 40 characters long. Have a look at the Recording Log
(for Single Protocol) or Generation Log (for Multiple Protocol) and see how long the

74
original value is. Have a look at the second recording made earlier and see how long
it was in that script. Turn on the Extended log (Run-Time Settings → Log →
Extended log → data returned from server) and have a look at how long it is in the
Execution Log.
If all occurrences of the script were much shorter that the maximum parameter
length, then the problem is either with the web_reg_save_param in the wrong place,
or that the boundaries are incorrect. Go back and look at the boundaries that you
selected, look at the placement of the web_reg_save_param. Is it immediately
before the statement that causes the server to reply with the data you are looking
for?
If, at any time, any of these values was close to being around 200 characters, or
exceeded 200 characters, then add a web_set_max_html_param_len statement to
the start of the script to make the maximum longer than 256 characters. For
example,
web_set_max_html_param_len(“length”);
This statement tells the replay engine to look for larger matches for the left and right
parameter. When it finds the left boundary, it will look ahead the max parameter
length for the right boundary. This setting is script wide and takes effect from when
it is executed; it only needs to appear in the script once. Looking for longer matches
uses up more memory and CPU processing to search through the returned text from
the server. For this reason, do not set it too high, or you will be making your script
less scalable. That is, you will reduce the number of Vusers that can run it on a
given machine. Try to have the maximum parameter length no more than 100
characters greater that what you are expecting.

75
9.13 There is a pop-up “Correlation warning” during recording
When you have auto-correlation with the option to “Issue a popup message and let
me decide online” turned on, you will see a pop-up warning when dynamic values
matching the correlation rule is detected.
Example:
You can set if you want to correlate it or ignore the value. You can also set the future
behavior for correlating as needed.

76
9.14 How to manually start the “Scan action for correlation” feature
To manually run the “Scan Action for correlation” feature, run the script once. Then,
select Vuser → “Scan Action for Correlations” to start the scan.
“Scan Action for Correlation” window does not come up after replay
This window may not come up if you have set to disabled it before. To re-enable this
feature:
1. Go to Tools → General options → Correlation tab.
2. Enable the option for “Show Scan for correlations popup after replay of Vuser.”

77
9.15 Why does Correlation Studio fail to detect all the dynamic values
The following are possible causes where Correlation Studio failed to detect all the
dynamic values, and suggestion to overcome it.
1. The difference is only a few bytes in length.

By default, the Web correlation only reports dynamic values that are greater than
four characters. To change the limit:
a. Go to Tools → General options → Correlation Tab → Advanced….
b. Click on the “Advanced…” button.
c. Modify the value for “Ignore Differences Shorter than x characters.”
2. The dynamic value is generated by the client and not by the server. For example,
you have a client side JavaScript that generates some important dynamic values.
Since the Web replay does not execute client side scripting, you will need to add
your custom code in the script to deal with this.
3. The replay response’s HTML has a different format than the recordings. For this,
you will need to perform manual correlation.

78
9.16 Additional Correlation Help Resources
The examples in the Function reference contain a lot of data and examples on how to
use these functions. Looking them over is recommended.
The Customer Support website has a video for download that goes over correlation.
You can get it from http://support.mercury.com. After logging in, go to Downloads
→ Browse. Select the Mercury Interactive downloads radio button, choose
“LoadRunner” from the product selection drop-down box, and click on the “Retrieve”
button. Under “Training,” select the “LoadRunner Web Script Correlation Training”
link.
Since most of applications does have a login and password to enter, therefore there
will be generation of a temporary session id, which requires Correlation to replay the
scripts. Please refer to go to mercury support site (http://support.mercury.com) for
more doubts and refer to these threads: 11806, 18587, 31968, 18587, 15543,
14470, 9583, 24264, 17241, and 12725

79
10.0 Some Trips and Tricks while dealing with VuGen
1. Consult your developer if you need help to identify the protocol used by the
application.
2. Some other applications, such as antivirus, VPN’s, firewall, and so on may
interfere with the recorder. In case of problems, always look to see what is
installed on the machine and try to disable software that looks like it is interfering
with socket level data.
3. Delete (or comment out) all the “web_add_cookie” statements in the script.
Some applications use explicit cookies to keep track of users. Therefore cookies
statements have to be commented out otherwise old cookies are sent to the
server again and it will not work.
4. Delete all the web_url(…..) statements in start of the script, which are
downloading the windows updates or something like that.
5. If you are using the Multiple Protocol recorder, you can use this option of Tools →
“Regenerate Vuser” to regenerate the script, if the earlier modified script is not
working fine.
6. Sometimes, you will encounter cases where the Web recorder (Single and Multi)
records some initial login steps but nothing else after that, even though it is still
using the HTTP protocol. This can happen if the application is dependent on the
cache in some way. By default, LoadRunner recording will disable the cache. To set
LoadRunner not to interfere with the cache setting, change the following in registry:
a. Go to Start → Run, and enter regedit to open the registry editor.
b. Navigate to HKEY_CURRENT_USER\Software\Mercury
Interactive\LoadRunner\Protocols\HTTP\Analyzer
c. Set AddNoCacheHeaderToHtml=0.
7. The following are limitations of the Single Protocol Web recorder. If any of the
following is causing a problem, you are recommended to switch to use the
Multiple Protocol web recorder to record.
Note: All the issues below can be resolved with Multiple Protocol Web recorder.
a. While recording, the Single Protocol Web recorder will redirect the client
requests to a local proxy, at localhost: 7777. For such, make sure that
you have the permission to change the LAN settings of the machine. To
verify:
i. Open Internet Explorer and go to Tools → Internet Options →
Connections → LAN Settings.

80
ii. Make sure that you can modify the entries here.
b. The Single Protocol Web recorder obtains the proxy setting from the
HKEY_CURRENT_USER registry hive. Verify the following to make sure
that it is set up correctly:
i. Go to Start → Run, and enter regedit to open the registry editor.
ii. Navigate to
HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\InternetSett
ings.
iii. Verify the non-default key, ProxySettingsPerUser. If the
iv. ProxySettingsPerUser value exists and has a value data of 0 (zero), set
it to 1. It is okay if you do not have that registry key. As long as
ProxySettingsPerUser is not set to one, proxy settings will be obtained
from the HKEY_CURRENT_USER registry hive.
8. To make permanent change in default settings in VuGenerator: (Reference:
Michael Warner, ID 2412 on Support Site)
To keep from having to change the run-time settings every time that you create a
new script, here is an easy way to save your own default settings.
1. Create a new script
2. Make the setting changes that you need to make.
3. Save the script
4. Now, copy the default.cfg file out of the directory of the script file that you just
created to the Program Files\Mercury Interactive\LoadRunner\template\{dir}.
The {dir} is whatever directory that you are creating your scripts from. For
example, a Web/HTML vuser directory is the \qtweb\ directory. You can
also change the init.c, end.c, or action.c if you seem to always have to make
changes to these files every time you create a new script.

81
11.0 Cookie
11.1 Definition for Cookie
A message given to a Web browser by a Web server. The browser stores the
message in a text file. The message is then sent back to the server each time the
browser requests a page from the server.
The main purpose of cookies is to identify users and possibly prepare customized
Web pages for them. When you enter a Web site using cookies, you may be asked
to fill out a form providing such information as your name and interests. This
information is packaged into a cookie and sent to your Web browser, which stores it
for later use. The next time you go to the same Web site, your browser will send the
cookie to the Web server. The server can use this information to present you with
custom Web pages. So, for example, instead of seeing just a generic welcome page
you might see a welcome page with your name on it.
There are 2 types of cookies
• Persistent Cookies
• Non-Persistent Cookies or Cookie
11.1.1 Persistent Cookie

Also called a permanent cookie, or a stored cookie, a cookie that is stored on a user’s
hard drive until it expires (persistent cookies are set with expiration dates) or until
the user deletes the cookie. Persistent cookies are used to collect identifying
information about the user, such as Web surfing behavior or user preferences for a
specific Web site.
11.1.2 Non-Persistent Cookie or Session Cookie

Also called a transient cookie, a cookie that is erased when the user closes the
Web browser. The session cookie is stored in temporary memory and is not retained
after the browser is closed. Session cookies do not collect information from the
user’s computer. They typically will store information in the form of a session
identification that does not personally identify the user.
Web_add_cookie Adds a new cookie or modifies an existing one.
Web_add_cookie_ex function adds a new cookie with the option to place the
cookie at the beginning of the cookie table, and to allow an empty domain.
Web_remove_cookie Removes the specified cookie
Web_cleanup_cookies Removes all cookies currently stored by the Vuser

82
11.2 How to Enable cookies

To enable cookies, follow the instructions below for the browser version you are
using.
Mozilla Firefox (1.0 final release and earlier)

• Go to the "Tools" menu.
• Select "Options".
• Select the "Privacy" icon in the left panel.
• Check the box corresponding to "Allow sites to set cookies".
• Click "OK" to save changes.
Netscape 7.1/Mozilla 5.0

• Select "Preferences" from the Edit menu.
• Click on the arrow next to "Privacy & Security" in the scrolling window to
expand. Under "Privacy & Security", select "Cookies."
• Select "Enable all cookies".
• Click "OK".
Microsoft Internet Explorer 6.0+

• Select "Internet Options" from the Tools menu.
• Click on the "Privacy" tab.
• Click the "Default" button (or manually slide the bar down to "Medium") under
"Settings".
• Click "OK".
Netscape Communicator 4.x

• Select "Preferences" from the Edit menu.
• Find the "Cookies" section in the "Advanced" category.
• To enable:
o Select "Accept all cookies" (or "Enable all cookies").
• Click "OK".

83
12.0 Timeout Settings

There are several reasons why you may wait a long time for a response:
• Others sharing your connection are sucking up bandwidth downloading mp3
files or photos.
• Your ISP is servicing too many subscribers at once.
• The Internet connection you are using is bogged down by flooding attacks and
spam.
• The site's IP address was not registered to a recognized DNS server.
• The site's firewall has blocked your IP address.
• The site's DNS server is not working.
• The site's telecom lines are overloaded.
• The site's servers are overloaded.
If you receive a timeout error such as the following, it may be the site's server or
your browser setting.
Microsoft Internet Explorer error 10060 connections timed out.

-or-
Internet Explorer cannot open the Internet site web address.
-or-
The operation timed out.
-or-
The page cannot be displayed. Cannot find server or DNS Error.
So that you do not wait endlessly for the server to come back with data when the
server has a problem, Internet Explorer imposes a time-out limit for the server to
return data. (Five minutes for versions 4.0 and 4.01)
In Internet Explorer 4.01 Service Pack 1 or later (IE 5, 5.5, 6), you can change the
timeout by adding a Receive Timeout DWORD value in registry key:
HKEY_CURRENT_USER\ Software\ Microsoft\ Windows\ Current Version\ Internet
Settings with a data value of (number of seconds)*1000. To set a 2 minute timeout
duration, set the Receive Timeout data value to (2*60*1000) = 120000. Restart
your computer.

84
13.0 Creating a Scenario using LoadRunner Controller
To test your system with LoadRunner, you must create a scenario—a file with
information about the test session. The scenario is the means by which you emulate
a real-life user. The scenario contains information about how to emulate real users:
the groups of virtual users (Vusers), the test scripts the Vusers will run, and the load
generator machines upon which to run the scripts.
13.1 Scenario:
A scenario defines the events that occur during each testing session.
For e.g.:- a scenario defines and controls the number of users to emulate, the
actions that they perform, and the machines on which they run their emulations.
There are 2 methods for creating a scenario:
• Manual Scenario.
• Goal-Oriented Scenario.
13.1.1 Manual Scenario:

In Manual Scenario, you create the scenario yourself by defining the number of
Vuser groups you want to run and building a schedule for the LoadRunner to run
these groups.
13.1.2 Manual Scenario Using Percentage Mode

By using the Percentage mode we can distribute the No. of Virtual users to distribute
the Scripts.
13.1.3 Goal Oriented Scenario

In Goal Oriented scenario, you define the goals you want your test to achieve and
LoadRunner automatically builds a scenario for you based on these goals. They are
five goals to achieve
• Number of Vusers
• Hits Per Second
• Transaction Response Time
• Transaction Per Second
• Pages downloaded per Minute.

85
13.2 Creating a Manual Scenario
To open the Controller:
• Select Start > Programs > LoadRunner > Controller.
• Click on the New Scenario button, New Scenario dialog opens with the list of
Vuser Scripts and select the default option Manual Scenario for scenario
types.
• Select the required script/scripts by clicking on the Add button.

• Click on Ok to add the script to the scenario.

86
• Scenario Group screen will be displayed.

• Enter the No. Of Vusers in the Quantity Column.
• Enter the IP address or the machine name of the system under load
generator column.
• Click on Add group button to add another group to the scenario, Add group
dialog opens and repeat the above steps.

87
13.3 The Controller window has two tabs, which correspond to two views:
Design view this view displays a list of all the Vuser groups/scripts in a scenario,
and the load generator machines, and number of Vusers assigned to each
group/script. This view also displays basic information about the scenario schedule
(manual scenario) or goal (goal-oriented scenario).
Run view Displays information on the running Vusers and Vuser groups, as well as
online monitor graphs. In addition, if you select View > Show Output, the Controller
opens the Output window which displays error, warning, notification, debug, and
batch messages generated during scenario execution.
13.4 Creating Vuser Groups

A scenario consists of groups of Vusers, which emulate human users interacting with
your application. When you run a scenario, the Vusers generate load on the server,
and LoadRunner monitors the server and transaction performance.
You create Vuser groups from the Scenario Groups window of the Controller.
The following figure shows the scenario group window.

88
13.4.1 To create Vuser Groups:

1. Click the Add Group button to the right of the Scenario Groups window.
The Add Group dialog box opens:

89
2. In the Group Name box, enter a name for the Vuser group.
3. From the Vuser Quantity box, select the number of Vusers that you want to create
in the group.
4. Select a load generator from the Load Generator Name list. The Load Generator
list contains all load generators that you previously added to the scenario.
5. To use a load generator that does not appear, select Add from the Load Generator
Name list. The Add Load Generator dialog box opens: Type the name of the load
generator in the Name box. In the Platform box, select the type of platform on which
the load generator is running. By default, LoadRunner stores temporary files on the
load generator during scenario execution, in a temporary directory specified by the
load generator’s TEMP or TMP environment variables. To override this default for a
specific load generator, type a location in the Temporary Directory box.

90
6.Click OK to close the Add Group dialog box. The new group’s properties appear in
the Scenario Groups window
13.4.2 Adding Vusers to a Vuser Group

You add Vusers to a Vuser group and define their properties using the Add Vusers
dialog box.
To add Vusers to a Vuser group:

1. In the Vusers dialog box, click the Add Vuser(s) button. The Add Vusers dialog
box opens.
2. From the Group Name box, select the name of the Vuser group.
3. From the Quantity to add box, select the number of Vusers that you want to add
to the group.
91
4. Select a load generator from the Load Generator Name list.
5. Select a script from the script list. The script list contains all scripts that you
previously added to the scenario.
6. Click OK to close the Add Vusers dialog box. The new Vuser’s properties appear in
the Vusers dialog box.
13.5 Create a Manual scenario using Percentage Mode

• Click on Start ->Programs->LoadRunner ->Controller
Vuser Scripts.
• Select the Manual Scenario option and also the check the check box “User the
percentage option.”
• Click on Ok to add the script to the scenario
• Scenario Group screen will be displayed.

• Enter the No. Of Vusers in the Total No. Of Vusers field.
• Enter the IP address or the machine name of the system under load
generator column.
92
• Enter the percentage in the % field.
• Click on Add group button to add another group to the scenario, Add group
dialog opens and repeat the above steps.
13.6 Creating the Goal Oriented Scenario

• Click on Start ->Programs->LoadRunner ->Controller
Vuser Scripts.
• Select the Goal Oriented Scenario option
• Click on Ok to add the script to the scenario.
13.6.1 Goals for Scenario

Virtual Users:
Enter a target number of Vusers that you would like your scenario to reach.
Hits per second:
The number of requests has been sent to the server with in a second point of time is
known as Hits Per Second.
Transactions per second:
Enter a target number of transactions per second that you would like your scenario
to reach.
Transaction Response Time:
Enter a target transaction Response time and select minimum and maximum number
of Vusers.
HTTP Pages downloaded per minute:
Enter a target number of downloaded pages per minute and select minimum and
maximum number of Vusers for the scenario.
13.7 Transactional Throughput

The amount of data has been retrieved from the server is known transactional
throughput. Data received in the form Bytes/sec.

93
13.8 Scheduling a Scenario
After you create a scenario, you can set the time at which the scenario will begin
running. In addition, for a manual scenario, you can set the duration time of the
scenario or of the Vuser groups within the scenario. You can also select to gradually
run and stop the Vusers within the scenario or within a Vuser group.
Load runner provides several scheduling options for scenario execution.
• Delaying the scenario start
• Limiting the scenario duration
You can instruct LoadRunner to begin executing a scenario with a delay. You can
specify the number of minutes to wait from the time a run command is issued, until
the scenario begins.
You can also limit the time duration of a scenario. You specify the number of minutes
a scenario should be in the running state. When a scenario reaches its time
limitation, it finishes.
Delaying the Start of a Scenario For both manual and goal-oriented scenarios, you
can instruct LoadRunner to start running the scenario at a later point in time. You
can specify either the number of minutes you want LoadRunner to wait from the
time a Run command is issued, or the specific time at which you want the scenario
to begin.
To delay the start of the scenario:
1. Select Scenario > Start Time. The Scenario Start dialog box opens, with the
default option, without delay is selected.

94
2. Select with a delay of X (HH: MM: SS) and enter the amount of time (in hours:
minutes: seconds format) by which you want to delay the start of your scenario.
Alternatively, you can select at X (HH: MM: SS) on X and specify the time (in
hours: minutes: seconds format) and date for the start of the scenario.
3. Click OK to close the dialog box and save your settings.
The available properties are Duration, Initializing, Ramp Up, and Ramp Down.
Initializing: the number of Vusers to initialize to the ready state during the
specified time interval, this emulates a logon procedure usually done once a day.
Ramp Up: The pace at which Vusers run this script (i.e. Transition from Ready to
Run state). This usually emulates actions that are repeated multiple times.
Duration: The amount of time the current group participates in the scenario.
Ramp down: The pace at which Vusers are terminated, this setting is only
available if the group is set to run for a fixed duration.
To set the scheduling options for a scenario:
1. Select the Schedule By Scenario option.
2. To determine how to start the scenario, click the Ramp Up tab.

Choose one of the following options:
• Load all Vusers simultaneously: Starts all the Vusers in the scenario at once.
95
• Start X Vusers every X (HH:MM:SS): Begins running the specified number of
Vusers concurrently, and waits the specified time between Vuser ramp ups.
3. To set the duration of the scenario, click the Duration tab.

• Run until completion
• Run for X (HH:MM:SS) after the ramp up has been completed: Runs the
scenario for a specified amount of time, once all the Vusers have been
ramped up.
• Run indefinitely
4. To determine how to stop the scenario, click the Ramp Down tab.

• Stop all Vusers simultaneously: Stops all the Vusers in the scenario at once.

96
• Stop X Vusers every X (HH:MM:SS): Stops a certain number of Vusers
within a specified time frame.
5. To instruct LoadRunner to initialize Vusers before beginning to load them, select
initialize all Vusers before ramp up.
Note that LoadRunner will only begin to load the Vusers once they have all reached
the READY state.
6. Click OK to close the Schedule Builder and save your settings.
Scheduling Vuser Groups

After you create a Vuser group, you can schedule the group’s script execution by
setting:
• The amount of time after the start of the scenario that the group must wait
before it starts running.
• The number of Vusers that will run within a specified period of time.
• The number of Vusers that will be stopped within a specified period of time.
• The amount of time the group will run.
To schedule a Vuser Group:

1. Select the Scheduling By Group option.

97
2. Select a group from the box on the left.

3. To set the start time for the group, click the Start Time tab.
Choose one of the following three options:

• Start the group at the beginning of the scenario
• Start X after the scenario begins: Waits the specified amount of time before
running the group.
• Start when group X finishes: Begins running the group after the specified
group has finished running.
4. To set the ramp up for the group click the Ramp Up tab.

98

• Load all of the Vusers simultaneously: Starts all the Vusers in the at once.
• Start X Vusers every X (HH:MM:SS): Begins running the specified number of
Vusers concurrently, and waits the specified time between Vuser Ramp Up.
5. To set the duration of the group, click the Duration tab.

• Run until completion
• Run for X (HH:MM:SS) after the ramp has been completed: Runs the group
for the specified amount of time, once all the Vusers have been ramped up.

99
6. To determine how to stop the Vuser group, click the Ramp Down tab.

• Stop all Vusers simultaneously: Stops all the Vusers in the group at once.
• Stop X Vusers every X (HH:MM:SS): Stops a certain number of Vusers within
a specified time frame.
7. Click OK to close the Schedule Builder and save your settings.

100
14.0 Running a Scenario
Once you have designed your scenario, you are ready to run it. You can control the
Vusers and Vuser groups and monitor their performance online using the Run view of
the LoadRunner Controller. The following figure shows the Run view.
During scenario execution, you use the Scenario Groups window in the Run view to
monitor the actions of all the Vusers and Vuser groups in the scenario. The Status
field of each Vuser group displays the current state of each Vuser in the group.
You can also manipulate individual Vusers within the Vuser groups you have defined
by selecting a group and clicking the Vusers button. The Vusers dialog box appears,
with a list of the ID, Status, Script, Load Generator, and Elapsed Time (since the
beginning of the scenario) for each of the Vusers in the group

101
Note that you can detach the Scenario Status window from the Run view, thereby
enlarging the Scenario Groups window.
While the scenario runs, the Vusers and load generators send error, notification,
warning, debug, and batch messages to the Controller. You can view these messages
in the Output window (View > Show Output).

102
Viewing Vusers During Execution
LoadRunner lets you view Vuser activity during a scenario:
• On the Controller load generator machines, you can view the Output window,
monitor Vuser performance online, and check the status of Vusers executing
the scenario.
• On remote machines, you can view the Agent summary with information
about the active Vusers.
14.1 Monitoring Vuser Status

During scenario execution, you can use the Scenario Groups window in the Run view
to monitor the actions of all the Vusers and Vuser groups in the scenario.
The Status field of each Vuser group displays the current state of each Vuser in the
group. The following table describes the possible Vuser states during a scenario.
Status Description
DOWN The Vuser is down.

PENDING The Vuser is ready to be initialized and is waiting
for an available load generator, or is transferring
files to the load generator. The Vuser will run when
the conditions set in its
Scheduling attributes are met.
INITIALIZING The Vuser is being initialized on the remote
machine.
READY The Vuser already performed the init section of the
script and is ready to run.
RUNNING The Vuser is running. The Vuser script is being
executed on a load generator.
RENDEZVOUS The Vuser has arrived at the rendezvous and is
waiting to be released by LoadRunner.
DONE.PASSED The Vuser has finished running. The script passed.
DONE.FAILED The Vuser has finished running. The script failed.
ERROR A problem occurred with the Vuser. Check the

Status field on the Vuser dialog box or the output

103
window for a complete explanation of the error.
GRADUAL EXITING The Vuser is completing the iteration or action it is
running (as defined in Tools > Options > Run-Time
Settings) before exiting.
EXITING The Vuser has finished running or has been
stopped, and is now exiting.
STOPPED The Vuser stopped when the Stop command was
invoked.
15.0 IP Spoofing
If the hardware configuration under test balances load across a “farm” of several (we
or database) servers, you can spoof how routers distribute work among those
servers so that each Vuser uses a unique IP address instead of same IP address for
its host machine. So to use this “IP spoofing” to emulate a more realistic pattern of
IP address:
• On each Vuser host machine use the IP wizard “new setting” dialog to enter
the IP address of the web server and the IP addresses to assign Vusers in
their stead. Individual addresses or—in a closed – network – a range of
addresses (from any IP class) can be specified.
• Reboot to refresh the server’s “Routing table” (done at start up)
• On the controller’s “Scenario” menu select “Enable IP spoofer”.

104
16.0 Monitoring a Scenario
Monitoring scenario execution using the LoadRunner online transaction, Web server
resource, Database server resource and Java performance monitors.
The following describes the online monitor user interface:
• Starting the Monitors.
• Configuring Online Monitors.
• Setting Monitor Options.
• Configuring Online Graphs.
• Configuring Online Measurements.
• Exporting Online Monitor Graphs.
• Viewing Data Offline
16.0.1 Online Monitoring

LoadRunner provides the following online monitors:
• Run-Time monitor displays the number and status of Vusers participating in
the scenario, as well as the number and types of errors that the Vusers
generate. It also provides the User-Defined Data Point graph that displays the
real-time values for user-defined points in a Vuser script.
• Transaction monitor displays the transaction rate and response time during
scenario execution.
• Web Resource monitors measures statistics at the Web server(s) during
scenario runs. It provides information about the number of Web connections,
throughput volume, HTTP responses; server retries, and downloaded pages
during the scenario.
• Network Delay monitor displays information about the network delays on
your system. To activate the Network Delay monitor, you must set up the
network paths to monitor before you run your scenario.
• The Firewall monitor measures statistics at the firewall servers during the
scenario. To activate the Firewall monitor, you must set up a list of resources
to monitor before you run your scenario.
• The Database Server Resource monitors measure statistics related to the
SQL server, Oracle, Sybase, and DB2 databases. To activate the Database
Server Resource monitors, you must set up a list of measurements to monitor
before you run your scenario.

105
• The Streaming Media monitors measure statistics at the Windows Media
Server and RealPlayer audio/video servers, as well as the RealPlayer client. To
activate the Streaming Media monitors, you must set up a list of resources to
monitor before you run your scenario.
• The ERP Server Resource monitor measures statistics at the ERP servers
during the scenario. To activate the ERP Server Resource monitor, you must
set up a list of resources to monitor before you run your scenario.
• The Java Performance monitors measure statistics of Enterprise Java Bean
(EJB) objects and Java-based applications, using EJB, JProbe, Sitraka
JMonitor, and TowerJ Java virtual machines. To activate the Java Performance
monitors, you must set up lists of resources to monitor before you run your
scenario.
16.0.2 Starting the Monitors

To start the online monitors:
1. Start the scenario. Select the Vuser groups you want to run and click the Start
Scenario button, or choose Scenario > Start.
2. Click the Run tab. The default graphs are displayed below the Scenario Groups
window.
3. Double-click a graph to maximize it. Repeat the operation to restore the tiled
view.
4. Click the "+" in the left pane to expand the graph tree. To hide the graph tree
view, select View > Hide Available Graphs, or click the X button in the right-hand
corner of the Available Graphs list.
5. Select a graph from the tree and drag it into the right pane. You can also drag
graphs between panes.

106
16.0.3 Configuring Online Monitors

Using LoadRunner it is possible to configure the settings for your online monitors.
And also, we can set graph measurements and properties, such as the sampling
time, the colors of the lines, and the scale of the graph.
Monitor options: global sampling rate, error handling, debugging, and the
frequency settings.
Graph properties: refresh rate, display type, graph time for the x-axis, and the y-
axis scale.
Measurement settings: line color, scale of the y-axis, and whether to show or hide
the line.

107
16.0.4 Setting Monitor Options
Before running your scenario, you can set monitor options in the following areas:
Sampling Rate: The sampling rate is the period of time (in seconds) between
consecutive samples. By default, the online monitor samples the data at intervals of
three seconds. If you increase the sampling rate, the data is monitored less
frequently. This setting applies to all graphs.
Error Handling: You indicate how LoadRunner should behave when a monitor error
occurs—issue a popup message box (default) or send error messages to the Output
window.
Debug: The online monitor provides debugging capabilities. It displays the debug
messages in the output log. For the Network monitor, you can indicate the debug
(detail) level of messages sent to the log, ranging from 1-9.
Frequency: You set the frequency at which the monitor sends updates to the
Controller for the Transaction, Data Point, and Web Resource graphs. The data is
averaged for the frequency period defined, and only one value is sent to the
Controller.
To set monitor options:
1. Select Tools > Options and select the Monitors tab.
2. Specify the frequency at which the monitor should send updates to the Controller
for the Transaction, Data Point, and Web Resource graphs. The default value is 5
seconds. For a small scenario, it is recommended that you use a frequency of 1. For
a large scenario, it is recommended that you use a frequency of 3-5.
3. Enter a sampling rate.

108
4. Set the desired Error handling option.
5. To display debug messages in the Output window, select the Display Debug
Messages check box. For the Network monitor, specify a Debug level from 1-9.
6 Click OK to save your settings and close the Options dialog box.
16.0.5 Configuring Online Graphs

You can customize your graph in the following areas:
• Refresh Rate: The refresh rate is the interval in which the graph is refreshed
with new data. By default, the graph is refreshed every five seconds. If you
increase the refresh rate, the data is refreshed less frequently.
• X-Axis Style: By using this it is possible to displays the x-axis time: Don’t
Show, Clock Time, or Relative to Scenario Start. The Don’t Show setting
instructs LoadRunner not to display values for the x-axis. The Clock Time
setting displays the absolute time, based on the system clock. The Relative to
Scenario Start setting displays the time relative to the beginning of the
scenario.
In the following example, the graph is shown with the Don’t Show and Clock Time
options:
• Graph Time: The Graph Time settings indicate the scale for a graph’s x-axis
when it is time-based. A graph can show 60 or 3600 seconds of activity. To
see the graph in greater detail, decrease the graph time. To view the
performance over a longer period of time, increase the graph time. The
available graph times are: Whole scenario, 60, 180, 600, and 3600 seconds.
• Display Type: You can specify whether LoadRunner displays the Network
Delay Time graph as a line, pie, or area graph. By default, the graph is
displayed as a line graph.
109
• Y-Axis Style You can instruct LoadRunner to display graphs using the default
y-axis scale, or you can specify a different y-axis scale. Click Automatic if
you want LoadRunner to use the default y-axis values.
To customize your graphs:

1. Select the online graph you want to configure (in either the right or left pane) and
choose Monitors > Online Graphs > Configure. Alternatively, right-click a graph
and select Configure. The Graph Configuration dialog box opens.
2. To apply the dialog box settings to all graphs, select Apply to all graphs.
3. Enter the desired refresh rate—the time between graph updates—in the Refresh
Rate box.
4. Select a style for the x-axis from the Time box.
5. Select a value from the Graph Time box. The graph time is the time in seconds
displayed by the x-axis.
6. For the Network Delay Time graph, select a graph style (Line, Pie, or Area) from
the Display Type box.
7. Select a maximum or minimum value for the y-axis, or choose Automatic to view
graphs using the default y-axis scale.
8. Click OK to save your settings and close the Graph Configuration dialog box.

110
16.0.6 Configuring Online Measurements
You can configure the following online measurement settings:
• Changing Line Colors: LoadRunner assigns a unique color to each
measurement. You can modify the color using the configuration interface.
• Setting the Scale of the Measurement: You can modify the scale of a
measurement—the relationship between the y-axis and the graph’s actual
value. For example, a scale set at 1 indicates that the measurement’s value is
the value of the y-axis. If you choose a scale of 10, you must divide the y-
axis value by 10 to obtain the true value of the measurement.
In the following example, the same graph is displayed with a scale of 1 and 10.
• Showing and hiding resources: By default, the resource monitor displays a

line for each item in the resource list. You can hide the line for any of the
monitored resources in order to focus on a specific measurement and scale
factor.
16.0.7 Exporting Online Monitor Graphs
LoadRunner allows you to export the online graph to HTML for viewing at a later
stage. When you export to HTML, the legend is also displayed with the graph. You
can export all graphs or only the selected one.
To export online graphs to HTML:
1. To export a specific graph, select the graph you want to export and choose
Monitors > Online Graphs > Export to HTML. The Select Filename and Path
dialog box opens.
2. To export all graphs in the Online Monitor view, choose Monitors > Export
Online Graphs to HTML. The Select Filename and Path dialog box opens.
3. Specify a filename and path and click Save.

111
16.0.8 Viewing Data Offline
After monitoring resources during a scenario run, you can view a graph of the data
that was gathered using the LoadRunner Analysis. When you run the Analysis utility,
it processes the data and generates a graph for each measurement that was
monitored.

112
17.0 Performance Counters need to be captured
Performance counters to be captured are as follows:
• CPU Utilization
• Avg Disk Queue Length
• Network Interface
• System
• Server
• Process
• Physical Disk
• Logical Disk
• Memory
Few Tips on Resources utilization of the Servers

Parameter Tips
None of the CPUs should have utilization of more than
Utilization 80 percent.
Avg. Disk Queue Length Should not be more than 2.
Load Average More than three processes should not wait for the CPU.
Any non-DB, system processes utilizing CPU intensively
CPU Intensive Processes warrant attention.
Swapping Minimal to no swapped-out processes
Paging Minimize page faults
Data Buffer Hit Ratio More than 70 percent
Disk should have less than 50-70 I/Os per second. Also,
High Disk Activity the disks should be less than 60 percent busy.
Minimal to no disk request queue. A queue of 2-4
Long Disk Queues warrants attention.
Un-indexed Tables All the tables should have at least one Primary Key.

113
18.0 Load Runner Analysis
During scenario execution, Vusers generates results of data as they perform their
transactions. To monitor the scenario performance during test execution, use the
online monitoring tools. To view a summary of the results after test execution, you
can use one or more of the following tools:
• Vuser log files contain a full trace of the scenario run for each Vuser.
These files are located in the scenario results directory. (When you run a
Vuser script in standalone mode, these files are placed in the Vuser script
directory.)
• Controller Output window displays information about the scenario run. If
your scenario run fails, look for debug information in this window.
• Analysis graphs help you determine system performance and provide
information about transactions and Vusers. You can compare multiple
graphs by combining results from several scenarios or merging several
graphs into one.
• Graph Data and Raw Data views display the actual data used to generate
the graph in a spreadsheet format. You can copy this data into external
spreadsheet applications for further processing.
• Report utilities enable you to view a Summary HTML report for each graph
or a variety of Performance and Activity reports.
18.1 Analyzing the results

Once the Scenario is executed and the results are stored, results can be analyzed
through the tool LoadRunner Analysis.
Steps to open the results file in LR analysis
1.Start->Programs-> Load Runner->Analysis
2.Click on the New Button.
3.Select the Results file.
4.Click on the graphs link in the left navigation bar.
5.You will see different graphs on the right hand side pane.

114
18.2 Summary Report
The summary Report provides the information about the scenario execution. It
provides the information like Running Vusers, Throughput, Hits Per second, HTTP
Responses per Second, Transaction Summary and Average Transaction Response
time. 90 percent column indicates the maximum response time for ninety percent of
the Transactions.
18.2.1 Transaction Percentile

Summary report contains a percentile column showing the response time of 90% of
transaction (90% of transaction fall with in this amount of time). If you want to
change the value of the default 90% percentile, enter the new figure in the
transaction percentile box. Since this is an application level setting, the column name
changes to the new percentile figure (for e.g.: 80% percentile only on the next
invocation of the analysis.

115
18.3 Analysis Graphs
The Analysis graphs are divided into the following categories:
• Vuser graphs display information about Vuser states and other Vuser
statistics.
• Error graphs provide information about the errors that occurred during the
scenario.
• Transaction graphs provide information about transaction performance and
response time.
• Web Resource graphs provide information about the throughput, hits per
second, HTTP responses per second, number of retries per second, and
downloaded pages per second for Web Vusers.
• Web Page Breakdown graphs provide information about the size and
download time of each Web page component.
• User-Defined Data Point graphs display information about the custom data
points that were gathered by the online monitor.
• System Resource graphs show statistics relating to the system resources
that were monitored during the scenario using the online monitor.
18.4 Merging the graphs

There are three types of techniques used for merging the graphs.
They are:
A. Overlay
B. Tile
C. Correlate.
Overlay:
If you want to merge the two graphs by using overlay technique then it will displayed
as elapsed time in seconds on X- axis and contents of Y- axis. It displays the
contents of shared values on Y- axis.
Tile:
It displays the graph one above the other by using X-axis..
Correlate:
It displays the graph against to each other

116
18.5 Starting the Analysis
The analysis is the Load Runner component that processes results gathered during a
scenario execution and generates graphs and reports. You can open the Analysis
through the Load Runner program group as an independent application, or directly
from the Controller.
• To open the new Analysis utility as an independent application, choose
Analysis from the LoadRunner Program Group.
• To open the Analysis directly from the Controller, select Results >
Analyze Results. This option is only available after running a scenario.
18.6 Collating Execution Results

When you run a scenario, by default all Vuser information is stored locally on each
Vuser host. After scenario execution the results are automatically collated or
consolidated—results from all of the hosts are transferred to the results directory.
Disabling automatic collation, by choosing Results > Auto Collate Results from
the Controller window, to clear the check mark adjacent to the option.
To manually collate results, choose Results > Collate Results. If your results have
not been collated, the Analysis will automatically collate the results before generating
the analysis data.
18.7 Viewing Summary Data

In large scenarios, with results exceeding 100 MBs, it can take a while for the
Analysis to process the data. While LoadRunner is processing the complete data, you
can view a summary of the data collected.
To view the summary data, choose Tools > Options, and select the Result
Collection tab. Select Display summary data while generating complete data if
you want the Analysis to process the complete data graphs while you view the
summary data, or select Generate summary data only if you do not want
LoadRunner to process the complete Analysis data.
Note: The following graphs are not available when viewing summary data only:
Rendezvous, Data Point (Sum), Web Page Breakdown, Network Monitor, and Error
graphs.

117
18.8 Working with Analysis Graphs
The Analysis provides a number of utilities that enable you to customize the graphs
in your session so that you can view the data displayed in the most effective way
possible.
Using the Analysis utilities, you can determine:
• Point’s coordinates or drill down on a graph.
• Enlarge a section of a graph.
• Change the granularity of a graph’s x-axis.
• View a graph’s data as a spreadsheet or as raw data.
18.8.1 Determining a Point’s Coordinates

You can determine the coordinates and values at specific points in a graph. Place the
cursor over the point you want to evaluate. The Analysis displays the axis values and
other grouping information. The following figure represents the point’s coordinates.
18.8.2 Enlarging a Section of a Graph

Graphs initially display data representing the entire duration of the scenario. You can
enlarge any section of a graph to zoom in on a specific period of the scenario run.
For example, if a scenario ran for ten minutes, you can enlarge and focus on the
scenario events that occurred between the second and fifth minutes.
To zoom in on a section of the graph:
1. Click inside a graph.
2. Move the mouse pointer to the beginning of the section you want to enlarge, but
not over a line of the graph.

118
3. Hold down the left mouse button and draw a box around the section you want to
enlarge.
4. Release the left mouse button. The section is enlarged.
5. To restore the original view choose Clear Display Option from the right click
menu.
18.8.3 Changing the Granularity of the X-Axis

You can make the graphs easier to read and analyze by changing the granularity
(scale) of the x-axis. The maximum granularity is half of the graph’s time range. To
ensure readability and clarity, the Analysis automatically adjusts the minimum
granularity of graphs with ranges of 500 seconds or more.
To change the granularity of a graph:
1. Click inside a graph.
2. Select View > Set Granularity, or click the Set Granularity button. The
Granularity dialog box opens.
3. Enter a new granularity value in milliseconds, minutes, seconds, or hours.

4. Click OK.
For example, the Hits per Second graph is displayed using different granularities.
The y-axis represents the number of hits per second within the granularity interval.
For a granularity of 1, the y-axis shows the number of hits per second for each one-
second period of the scenario.
For a granularity of 5, the y-axis shows the number of hits per second for every five-
second period of the scenario.

119
For a granularity of 10, the y-axis shows the number of hits per second for every
ten-second period of the scenario
In the above graphs, the same scenario results are displayed in a granularity of 1, 5,
and 10. The lower the granularity, the more detailed the results. For example, using
a low granularity as in the upper graph, you see the intervals in which no hits
occurred. It is useful to use a higher granularity to study the overall Vuser behavior
throughout the scenario. By viewing the same graph with a higher granularity, you
can easily see that overall, there was an average of approximately 1 hit per second.

120
18.8.4 Viewing the Data as a Spreadsheet and as Raw Data
The Analysis allows you to view graph data in two ways:
Spreadsheet View
You can view the graph displayed by the Analysis in spreadsheet format using the
Graph Data tab below the graph.
Raw Data View
You can view the actual raw data collected during test execution for the active
graph. The Raw Data view is not available for all graphs. Viewing the raw data
can be especially useful for:
• Determining specific details about a peak—for example, which Vuser was

running the transaction that caused the peak value(s).
• Performing a complete export of unprocessed data for your own

spreadsheet application.

121
19.0 Understanding Analysis Reports
After running a scenario, you can view reports that summarize your system’s
performance. The Analysis provides the following reporting tools:
• Summary report: The Summary report provides general information about
the scenario run. You can view the Summary report at any time from the
Analysis window.
• HTML reports: The Analysis creates an HTML report for each one of the open
graphs.
• Transaction reports: Transaction reports provide performance information
about the transactions defined within the Vuser scripts. These reports give
you a statistical breakdown of your results and allow you to print and export
the data.
19.1 Viewing Summary Reports
The Summary report provides general information about scenario execution. This
report is always available from the tree view or as a tab in the Analysis window. It
lists statistics about the scenario run and provides links to the following graphs:
Running Vusers, Throughput, Hits Per Second, HTTP Responses per Second,
Transaction Summary, and Average Transaction Response Time.
19.2 Creating HTML Reports

The Analysis lets you create HTML reports for your scenario run. It creates a
separate report for each one of the open graphs and a Summary report. The
Summary report is identical to the Summary report that you access from the
Analysis window. The report also provides a link to an Excel file containing the graph
data.
To create HTML reports:

1. Open all graphs that you want to be included in the report.
2. Choose Reports > HTML Report or click the Create HTML Report button. The
Select Report Filename and Path dialog box opens.
3. Specify a path and file name for the HTML report and click OK.
4. To view an HTML report for one of the graphs, click on its link in the left frame.
5. To copy the HTML reports to another location, be sure to copy the filename and
the folder with the same name. For example, if you named your HTML report test1,
copy test1.html and the folder test1 to the desired location.

122
19.3 Working with Transaction Reports
LoadRunner’s Transaction reports are divided into the following categories:
• Activity reports provide information about the number of Vusers and the
number of transactions executed during the scenario run. The available
Activity reports are Scenario Execution, Failed Transaction, and Failed Vusers.
• Performance reports analyze Vuser performance and transaction times. The
available Performance reports are Data Point, Detailed Transaction, and
Transaction Performance by Vuser.
Note: In order to view a report, you must generate it from the Analysis window.
LoadRunner reports are displayed in a Report Viewer. You can print, save, or export
the data using the viewer.
16.13 Selecting and Displaying Reports
The Analysis provides several built-in reports, which contain detailed summaries
about the scenario, the transactions and Vusers.
To display a report:
1. Open the desired Analysis session file (.lra extension), or LoadRunner result file
(.lrr extension), if it is not already open.
2. From the Reports menu choose a report. The report is generated and displayed.
You can display multiple copies of the same report.
19.4 Scenario Execution Report

The Scenario Execution report is an Activity report that provides details about major
events that occurred during the scenario run. This includes information on every
Vuser, such as when it was ready to run and for how long it ran.

123
Failed Transaction Report
The Failed Transaction report is an Activity report that provides details about the
beginning time, end time, and duration of the failed, but completed transaction.
Failed Vuser Report

The Failed Vuser report is an Activity report that provides details about all Vusers
that were in the ERROR, STOPPED, or DONE: FAILED states during the scenario
execution. The Ready At and Running At times are relative to the computer’s system
clock.
In this scenario, all five Vusers were stopped.

124
19.5 Detailed Transaction Report
The Detailed Transaction (by Vuser) report is a Performance report that provides a
list of all transactions executed by each Vuser during a scenario. The report provides
details about the execution time of each transaction per Vuser.
The following values are reported:
Start time: the system time at the beginning of the transaction
End time: the actual system time at the end of the transaction, including the think
time and wasted time.
Duration: the duration of the transaction in the following format: hrs: minutes:
seconds: milliseconds. This value includes think time, but does not include wasted
time.
Think time: the Vuser’s think time delay during the transaction.
Wasted time: the LoadRunner internal processing time not attributed to the
transaction time or think time. (Primarily RTE Vusers)
Results: the final transaction status, either Pass or Fail.
19.6 What is the 90th percentile and how is it calculated?
The 90th percentile is a measure of statically distribution, not unlike the median. The
median is the middle value. The median is the value for which 50% of the values
were bigger, and 50% smaller. The 90th percentile tells you the value for which 90%
of the data points are smaller and 10% are bigger.
Statistically, to calculate the 90th percentile value:
• Sort the transaction instances by their value.

• Remove the top 10% Instances.
• The highest value left is the 90th percentile.

125
Example:
There are ten instances of transaction "t1" with the values 1,3,2,4,5,20,7,8,9,6 (in
sec).
• Sort by value – 1,2,3,4,5,6,7,8,9,20

• Remove top 10% --remove the value “20”.
• The highest value left is the 90th percentile – 9 is the 90th percentile value.
The 90th percentile value answers the question, "What percentage of my

transactions have a response time less than or equal to the 90th percentile value?"
Given the above information, here is how Load Runner calculates the 90th percentile.
In analysis 7.0 and above:
Each value is counted in a range of values. For example, 5 can be counted in a range
of 4.95 to 5.05, 7.2 in a range of 7.15 to 7.25. The 90% is taken from the range of
values that the number of transaction in it and before it is >= (0.9 * Number of
Values).
This difference in the methods can lead to different 90% values. Again, both
methods lead to correct values as defined by the 90th percentile. However, the
algorithm to calculate these figures has changed in Load Runner 7 and above.

126
19.7 Root cause Analysis for finding the Bottlenecks
Root cause analysis process
• Compare results against goals - confirm performance has not met

expectations.
• Identify potential bottlenecks - list all the pieces of the system which
might have caused that slowdown.
Correlate results
Determine the most likely culprit by correlating transaction times and backend
monitor metrics.

127
19.8 Did you meet your goals?
Meeting your goals

The Summary Report provides a high-level view of the results of a test
The Summary Report should be your first stop after a test run
The key column to look at is the 90 Percent column
This column indicates the maximum response time for ninety percent of the
transactions.
Looking at this column gives you a good idea of the overall performance of the
transactions.
Every report in the analysis tool contains valuable data. The data is summarized into
a high-level report in Summary Report. If unacceptable response times and failures
are seen this shows that the load testing did not achieve the desired goal. Employ
systematic Strategies to find the root cause of a problem.

128
Results Analysis - Setting the Stage
Our load testing goal is to be able to support 100 users with < 5 second transaction
response time across all transactions. Any issues that affect this should be identified
and resolved.
Note: That we have unacceptable maximum response times and are beginning to
see failures. We will try to identify the cause of these failures in the coming slides.
19.9 Average Transaction Response Time
Details transaction response throughout the test.
Average Response Time Graph
Identifies problematic transactions.
Identifies problematic points in the test.
As we look through the data, we can begin dissecting the problem. Response time
Exceeded the goal at about 20+ minutes into the test. What else was happening
then?

129
19.10 Average Transaction Response time under Load
• Details transaction response time as a function of load.

• Identifies under what load conditions transaction times begin to degrade.
• By looking at the Average Transaction Response Time under Load, we can see
response time degrades above ~70 users. The goal was to support 100 users
at <5 seconds. Clearly, we will need to make changes to the system to
support this business goal. But where is the problem?

130
19.11 Transaction Response Time Percentile
• Details transaction response time as a service level.

• Identifies percentage of transactions complete over time.
• The project manager has defined the Service Level Agreement as 99.9% (or
greater!).With failing transactions and unacceptable response times, this
problem is causing sleepless nights and missed Service Level commitments.
Or is it? Which customers are being affected?

131
19.12 Transaction Response Time Distribution
• Details transaction response time as a distribution count.

• Identifies number of transactions complete over time.
• By drilling down on a transaction (Credit), we can see that most of the
customers seem to be within the Service Level. However, there are still far
too many transactions exceeding the 5-second threshold.
Working with the Data
• The amount of data that can be gathered during a test is staggering. Without
some effective way of manipulating this data, diagnosing issues would be
impossible.

132
19.13 Load Runner Analysis provides:
Filtering to hide unwanted data from analysis.
Regrouping to assemble data as desired by merging graphs, tiling, and
autocorrelation.
Duplicate graphing to separate data.
Legend filtering to update graph displays quickly.
Drill-Down capability.
Once you have applied the desired settings you can save the session as a template
and apply the same template to other results files. Templates enable you to save the
current filter and display options and use them in another session.
You save, apply, and edit templates using the Template dialog box.
To save the analysis session as a template:
1. Select TOOLS→ TEMPLATES→ SAVE AS TEMPLATE.
Open a new Graph

133
• Click the “+” <New Graph> icon on the toolbar menu. The Open a New
Graph window opens.
• Select the graph that you need.
• Click the Open Graph button to open the graph.
• Only graphs which contain data are selectable.
Drilldown
Setting Filters
• Filters let you display only a specific transaction status, transaction name, group,
Vuser, or other condition in the Summary Report.
• You can set filters globally or for the selected graph.
• Select criteria and values for each filter condition that you want to employ.

134
Analysis Session File Extensions
• When you work with the Analysis tool, you work within a session that contains at
least one set of scenario results contained in a file ending with the .lrr extension.
• After the results are processed by the Analysis tool, the file is saved with the .lra
extension.
• If you want to do cross scenario analysis of the results, then do not delete the .lrr
files.
• Cross scenario analysis can only be done if the .lrr file is avail
19.14 Isolating Network
• As load increases, the throughput and hits graphs should reflect the increase.
• A fall-off in throughput under increasing load could indicate a problem with
network saturation.

135
19.15 Isolating Network Issues
The first step in isolating the issue in a specific subsystem is to understand how the
network performed during the test.
By looking at these three graphs, we see that Running Vusers, Hits per Second, and
Throughput graphs all correlate. As an analogy, think of a busy highway as your
network. The throughput can be represented by the ability of the highway to handle
the traffic. At the highway’s saturation point, the cars begin to bottleneck, and the
number of cars on the road flattens out to the maximum.
A bandwidth issue occurs, if throughput has flattened out while the number of Vusers
increases additionally, the number of Hits per second is like a parking lot (web
server). Each car is trying to find a spot, and when the lot is full, the cars are forced
to drive around until a Spot opens up.
If Hits per second flattens out as Vusers increase, there is likely a web server
connection issue. Since there is a direct correlation with Vusers, Hits and
Throughput, it does not seem likely that we have a network issue. Let’s validate that
the network was “clean”.

136
• Network Delay Time shows spikes in latency, indicating network issues.

• Network Sub-Path Time shows a “hop” with spikes, confirming network
issues.
• By looking at the Network Delay time and Sub-Path Time, we can see that the
average latency on the network during the test was low and consistent.
Consult your Network Subject Matter Expert if the data is not meaningful.

137
19.16 Isolating Server Issues
• Slow servers may reflect high load, misconfiguration, or other problems.

• Monitoring systems during a test will help find bottlenecks and
misconfigurations.
• We have eliminated the network as the cause of our response time issues,
and we also believe that our web server handled the number of connections
we requested. However, the web server is not eliminated yet from being the
bottleneck. Other configuration settings affect transaction response time.
• We begin to notice that CPU on the Web server seems to be consistently
running at 80% after 5 minutes into our test. Our problems began at ~20
minutes, so we now need to identify what other resources were affected
between the 5 minute-mark and the 20 minute-mark of the test.

138
• Servers should exhibit an average processor utilization of less than 70%

during normal load.
• Servers should also maintain physical memory availability throughout the
test.
• By looking at system-level resources, we can see that physical memory
begins to be consumed by the web server and is dangerously low at the 20
minute-mark. In addition, the lack of available physical memory has caused
the CPU utilization on the web server to begin rising. This occurs as the web
server uses “swapping” to disk for memory when no more physical memory
is available.
• We have identified the issue. As a resolution, we will need to increase physical
memory and retest to measure the effectiveness of this change. Once again,
the data might be more meaningful to the server administrators. Do not
hesitate to involve Subject Matter Experts (SMEs).

139
19.17 Interpreting Graphs
When you see a measurement in the graph flatten out, it means that the hardware
or software has reached its capacity and cannot handle any extra load.
• A connection graph that flattens out under increasing load may signify a Web
server issue.
• A throughput graph that flattens out under increasing load suggests a network
bandwidth issue.
In summary, we have walked through a troubleshooting session from Load Runner
data. The Analysis has been provided as an introduction to the LR Analysis Tool, and
is by no means complete. Other reports and graphs may be necessary to do Root
Cause Analysis, and many are available inside LR Analysis.
19.18 Time to first buffer breakdown

140
Time to First Buffer is the period between a browser request and the first reply.
• Provides high level Server vs. Network determination.
Now that we have “solved” our Root Cause Analysis, let’s look at other data from LR
Analysis.
With regard to Time to First Buffer, it is useful to isolate “Server” vs. “Network” in
an effort to quantify where a majority of the time is spent. Here, we can see that the
“Server” has been identified as the bottleneck. However, in complex infrastructures,
there are likely many servers, and we would need to diagnose further.
19.19 Auto correlate time range
Right-click on any graph and select AUTO CORRELATE (or from the toolbar menu
select VIEW→ AUTO CORRELATE). This will open the Auto Correlate window.
The selected measurement is displayed in the graph.

141
Other measurements can be chosen with the MEASUREMENT TO CORRELATE list box.
The following settings configure the Auto Correlate tool to automatically demarcate
the most significant time period for the measurement in the scenario.
• Select either TREND or FEATURE in the SUGGEST TIME RANGE BY BOX.
Trend demarcates an extended time segment which contains the most
significant changes. Feature demarcates a smaller dimension segment which
makes up the trend.
• Click BEST for the segment of the graph most dissimilar to its adjacent
segments.
• Click NEXT for further suggestions, each one being successively less
dissimilar. If the SUGGEST TIME RANGE AUTOMATICALLY box is checked,
then suggestions are automatically invoked whenever the Measurement to
correlate item changes. Alternatively, you can manually specify the FROM and
TO values of a time period in
• the TIME RANGE tab (in hh:mm:ss format). You can also manually drag the
green and red vertical drag bars to specify the start and end values for the
scenario time range.
• If you applied a time filter to your graph, you can correlate values for the
complete scenario time range by clicking the DISPLAY button in the upper
right-hand corner of the dialog box.

142
19.20 Auto correlate correlation options
1. To specify the graphs you want to correlate with a selected measurement and the
type of graph output to be displayed, click the Correlation Options tab.
2. In the SELECT GRAPHS FOR CORRELATION section, choose the graphs whose
measurements you want to correlate with your selected measurement:
In the DATA INTERVAL section, select one of the following two options:
Automatic: Instructs the Analysis to use an automatic value, in order to calculate
the interval between correlation measurement polls.
Correlate data based on X second intervals: Enter the number of seconds you
want the Analysis to wait between correlation measurement polls.
In the OUTPUT section, select one of the following two options:
• Show the X most closely correlated measurements: Specify the number
of most closely correlated measurements you want the Analysis to display.

143
• Show measurements with an influence factor of at least X%: Specify
the minimum influence factor for the measurements displayed in the
correlated graph. Click OK. The Analysis generates the correlated graph you
specified. Note the two new columns (Correlation Match and Correlation) that
appear in the Legend tab below the graph.

144
20.0 Load Balancer
Distributing processing and communications activity evenly across a computer
network so that no single device is overwhelmed. Load balancing is especially
important for networks where it's difficult to predict the number of requests that will
be issued to a server. Busy websites typically employ two or more web servers in a
load-balancing scheme. If one server starts to get swamped, requests are forwarded
to another server with more capacity. Load balancing can also refer to the
communications channels themselves.
On the Internet, companies whose Web sites get a great deal of traffic usually use
load balancing. For load balancing Web traffic, there are several approaches. For
Web serving, one approach is to route each request in turn to a different server host
address in a domain name system (DNS) table, round-robin fashion. Usually, if two
servers are used to balance a workload, a third server is needed to determine which
server to assign the work to. Since load balancing requires multiple servers, it is
usually combined with fail over and backup services. In some approaches, the
servers are distributed over different geographic locations.
20.1 Memory Leak

A bug in a program that prevents it from freeing up memory that it no longer needs.
As a result, the program grabs more and more memory until it finally crashes
because there is no more memory left.
7A memory leak is the gradual loss of available computer memory when a program
(an application or part of the operating system) repeatedly fails to return memory
that it has obtained for temporary use. As a result, the available memory for that
application or that part of the operating system becomes exhausted and the program
can no longer function. For a program that is frequently opened or called or that runs
continuously, even a very small memory leak can eventually cause the program or
the system to terminate. A memory leak is the result of a program bug.
Some operating systems provide memory leak detection so that a problem can be
detected before an application or the operating system crashes. Some program
development tools also provide automatic "housekeeping" for the developer. It is
always the best programming practice to return memory and any temporary file to
the operating system after the program no longer needs it.

145
When a system does not correctly manage its memory allocations, it is said to leak
memory. A memory leak is a bug. Symptoms can include reduced performance and
failure.
20.2 Bottleneck
A bottleneck, in a communications context, is a point in the enterprise where the
flow of data is impaired or stopped entirely. Effectively, there isn't enough data
handling capacity to handle the current volume of traffic. A bottleneck can occur in
the user network or storage fabric or within servers where there is excessive
contention for internal server resources, such as CPU processing power, memory, or
I/O (input/output). As a result, data flow slows down to the speed of the slowest
point in the data path. This slow down affects application performance, especially for
databases and other heavy transactional applications, and can even cause some
applications to crash.
A bottleneck frequently arises from poor network or storage fabric designs.

Mismatched hardware selection is a common cause. For example, if a workgroup
server is fitted with a Gigabit Ethernet port but the corresponding switch port that
connects to the server only offers a legacy 10/100 Ethernet port, the slow switch
port will then pose a bottleneck to the server. Another design flaw common to
storage networks is excess fan-in, where multiple storage devices are connected to
the same switch port in order to maximize the use of that switch port's bandwidth.
For example, connecting multiple four- gigabit (GB) Fibre Channel storage devices to
the same switch port can easily overwhelm the switch port and result in performance
problems if multiple storage devices are active simultaneously. In many cases,
bottlenecks develop over time because administrators fail to track the increasing
demands of network and storage traffic.
Bottlenecks can also develop due to poor or sub-optimal configuration of switches or

host bus adapters (HBAs). For example, using multiple Fibre Channel ports to
connect devices within the storage switching fabric can improve storage availability
and performance but if the interconnected devices are not configured for load
balancing much of the benefit is lost. Similarly, bottleneck conditions can occur due
to hardware failures. From the previous example, suppose that one of two Fibre
Channel links should fail. Although failover should allow the storage device to remain
accessible, all the traffic that used to be carried by two links now fails over to one --

146
potentially resulting in a bottleneck if that traffic exceeds the bandwidth of a single
link.
Bottlenecks are typically located by systematically testing network performance at

various devices along a data path and isolating devices performing noticeably slower
than other points. Once identified, the bottleneck can usually be resolved by
reconfiguring, upgrading or replacing the offending device. At the network level, this
may involve upgrading a switch or HBA. For servers, a CPU or memory upgrade may
help or the server may need to be replaced entirely (for example, replacing an aging
single-CPU server with a newer dual-or quad-CPU server). Bottlenecks can often be
avoided by proactively monitoring traffic load trends over time and implementing
improvements before serious problems develop.

147
21.0 HTTP Status Codes
HTTP, Hypertext Transfer Protocol, is the method by which clients (i.e. you) and
servers communicate. When someone clicks a link, types in a URL or submits out a
form, their browser sends a request to a server for information. It might be asking
for a page, or sending data, but either way that is called an HTTP Request. When a
server receives that request, it sends back an HTTP Response, with information for
the client. Usually, this is invisible, though I'm sure you've seen one of the very
common Response codes - 404, indicating a page was not found. There are a fair few
more status codes sent by servers, and the following is a list of the current ones in
HTTP 1.1, along with an explanation of their meanings.
Informational
100 Continue
A status code of 100 indicates that (usually the first) part of a request has been
received without any problems, and that the rest of the request should now be sent.
101 Switching Protocols
HTTP 1.1 is just one type of protocol for transferring data on the web, and a status
code of 101 indicates that the server is changing to the protocol it defines in the
"Upgrade" header it returns to the client. For example, when requesting a page, a
browser might receive a status code of 101, followed by an "Upgrade" header
showing that the server is changing to a different version of HTTP.
Successful
200 OK
The 200-status code is by far the most common returned. It means, simply, that the
request was received and understood and is being processed.
201 Created
A 201-status code indicates that a request was successful and as a result, a resource
has been created (for example a new page).

148
202 Accepted
The status code 202 indicates that server has received and understood the request,
and that it has been accepted for processing, although it may not be processed
immediately.
203 Non-Authoritative Information
A 203-status code means that the request was received and understood, and that
information sent back about the response is from a third party, rather than the
original server. This is virtually identical in meaning to a 200-status code.
204 No Content
The 204-status code means that the request was received and understood, but that
there is no need to send any data back.
205 Reset Content
The 205-status code is a request from the server to the client to reset the document
from which the original request was sent. For example, if a user fills out a form, and
submits it, a status code of 205 means the server is asking the browser to clear the
form.
206 Partial Content
A status code of 206 is a response to a request for part of a document. Advanced

caching tools use this, when a user agent requests only a small part of a page, and
just that section is returned.
Redirection
300 Multiple Choices
The 300-status code indicates that a resource has moved. The response will also
include a list of locations from which the user agent can select the most appropriate.

149
301 Moved Permanently
A status code of 301 tells a client that the resource they asked for has permanently
moved to a new location. The response should also include this location. It tells the
client to use the new URL the next time it wants to fetch the same resource.
302 Found
A status code of 302 tells a client that the resource they asked for has temporarily
moved to a new location. The response should also include this location. It tells the
client that it should carry on using the same URL to access this resource.
303 See Other
A 303-status code indicates that the response to the request can be found at the
specified URL, and should be retrieved from there. It does not mean that something
has moved - it is simply specifying the address at which the response to the request
can be found.
304 Not Modified
The 304-status code is sent in response to a request (for a document) that asked for
the document only if it was newer than the one the client already had. Normally,
when a document is cached, the date it was cached is stored. The next time the
document is viewed, the client asks the server if the document has changed. If not,
the client just reloads the document from the cache.
305 Use Proxy
A 305-status code tells the client that the requested resource has to be reached
through a proxy, which will be specified in the response.
307 Temporary Redirect
307 is the status code that is sent when a document is temporarily available at a
different URL, which is also returned. There is very little difference between a 302-
status code and a 307-status code. 307 was created as another, less ambiguous,
version of the 302-status code.

150
Client Error
400 Bad Requests
A status code of 400 indicates that the server did not understand the request due to
bad syntax.
401 Unauthorized
A 401-status code indicates that before a resource can be accessed, the client must
be authorized by the server.
402 Payments Required
The 402-status code is not currently in use, being listed as "reserved for future use".
403 Forbidden
A 403-status code indicates that the client cannot access the requested resource.
That might mean that the wrong username and password were sent in the request,
or that the permissions on the server do not allow what was being asked.
404 Not Found
The best known of them all, the 404-status code indicates that the requested
resource was not found at the URL given, and the server has no idea how long for.
405 Method not Allowed
A 405-status code is returned when the client has tried to use a request method that
the server does not allow. Request methods that are allowed should be sent with the
response (common request methods are POST and GET).
406 Not Acceptable
The 406-status code means that, although the server understood and processed the
request, the response is of a form the client cannot understand. A client sends, as
part of a request, headers indicating what types of data it can use, and a 406 error is
returned when the response is of a type not i that list.
151
407 Proxy Authentication Required
The 407-status code is very similar to the 401-status code, and means that the
proxy must authorize the client before the request can proceed.
408 Request Timeout
A 408-status code means that the client did not produce a request quickly enough. A
server is set to only wait a certain amount of time for responses from clients, and a
408 status code indicates that time has passed.
409 Conflicts
A 409-status code indicates that the server was unable to complete the request,
often because a file would need to be edited, created or deleted, and that file cannot
be edited, created or deleted.
410 Gone
A 410-status code is the 404's lesser-known cousin. It indicates that a resource has
permanently gone (a 404 status code gives no indication if a resource has give
permanently or temporarily), and no new address is known for it.
411 Length Required
The 411-status code occurs when a server refuses to process a request because a
content length was not specified.
412 Precondition Failed
A 412-status code indicates that one of the conditions the request was made under
has failed.
413 Request Entity Too Large
The 413-status code indicates that the request was larger than the server is able to
handle, either due to physical constraints or to settings. Usually, this occurs when a

152
file is sent using the POST method from a form, and the file is larger than the
maximum size allowed in the server settings.
414 Request-URI Too Large
The 414-status code indicates the URL requested by the client was longer than it can
process.
415 unsupported Media Type
A server to indicate that part of the request was in an unsupported format returns a
415-status code.
416 Requested Range Not Satisfiable
A 416-status code indicates that the server was unable to fulfill the request. This
may be, for example, because the client asked for the 800th-900th bytes of a
document, but the document was only 200 bytes long.
417 Expectation Failed
The 417-status code means that the server was unable to properly complete the
request. One of the headers sent to the server, the "Expect" header indicated an
expectation the server could not meet.
Server Error
500 Internal Server Error
A 500 status code (all too often seen by Perl programmers) indicates that the server
encountered something it didn't expect and was unable to complete the request.
501 Not Implemented
The 501-status code indicates that the server does not support all that is needed for
the request to be completed.

153
502 Bad Gateway
A 502-status code indicates that a server, while acting as a proxy, received a

response from a server further upstream that it judged invalid.
503 Service Unavailable
A 503-status code is most often seen on extremely busy servers, and it indicates
that the server was unable to complete the request due to a server overload.
504 Gateway Timeout
A 504-status code is returned when a server acting as a proxy has waited too long
for a response from a server further upstream.
505 HTTP Versions Not Supported
A 505-status code is returned when the HTTP version indicated in the request is no
supported. The response should indicate which HTTP versions are supported.

154
22.0 Appendix
Commands
a) vmstat Command
b) ioStat Command
c) netstat Command
d) lockstat command
e) mpstat command
VMSTAT Command
Purpose:
It reports Virtual memory statistics.
Syntax:
vmstat [ -f ] [ -i ] [ -s ] [ PhysicalVolume ... ] [ Interval [ Count ] ]
Description
The vmstat command reports statistics about kernel threads, virtual memory, disks,
traps and CPU activity. Reports generated by the vmstat command can be used to
balance system load activity. These system-wide statistics (among all processors)
are calculated as averages for values expressed as percentages, and as sums
otherwise.
If the vmstat command is invoked without flags, the report contains a summary of
the virtual memory activity since system startup. If the -f flag is specified, the
vmstat command reports the number of forks since system startup. The
PhysicalVolume parameter specifies the name of the physical volume.
The Interval parameter specifies the amount of time in seconds between each report.
The first report contains statistics for the time since system startup. Subsequent
reports contain statistics collected during the interval since the previous report. If the
Interval parameter is not specified, the vmstat command generates a single report
and then exits. The Count parameter can only be specified with the Interval
parameter. If the Count parameter is specified, its value determines the number of
reports generated and the number of seconds apart. If the Interval parameter is

155
specified without the Count parameter, reports are continuously generated. A Count
parameter of 0 is not allowed.
The kernel maintains statistics for kernel threads, paging, and interrupt activity,
which the vmstat command accesses through the use of the knlist subroutine and
the /dev/kmem pseudo-device driver. Device drivers maintain the disk
input/output statistics. For disks, the average transfer rate is determined by using
the active time and number of transfers information. The percent active time is
computed from the amount of time the drive is busy during the report.
The following example of a report generated by the vmstat command contains the
column headings and their description:
kthr: kernel thread state changes per second over the sampling interval.
r Number of kernel threads placed in run queue.
b Number of kernel threads placed in wait queue (awaiting resource, awaiting

input/output).
Memory: information about the usage of virtual and real memory. Virtual pages are
considered active if they have been accessed. A page is 4096 bytes.
avm Active virtual pages.
fre Size of the free list.
Note: A large portion of real memory is utilized as a cache for file

system data. It is not unusual for the size of the free list to
remain small.
Page: information about page faults and paging activity. These are averaged over
the interval and given in units per second.
re Pager input/output list.
pi Pages paged in from paging space.

156
po Pages paged out to paging space.
fr Pages freed (page replacement).
sr Pages scanned by page-replacement algorithm.
cy Clock cycles by page-replacement algorithm.
Faults: trap and interrupt rate averages per second over the sampling interval.
in Device interrupts.
sy System calls.
cs Kernel thread context switches.
Cpu: breakdown of percentage usage of CPU time.
us User time.
sy System time.
id CPU idle time.
wa CPU cycles to determine that the current process is wait and there is pending disk
input/output.
Disk: Provides the number of transfers per second to the specified physical volumes
that occurred in the sample interval. The PhysicalVolume parameter can be used to
specify one to four names. Transfer statistics are given for each specified drive in the
order specified. This count represents requests to the physical device. It does not
imply an amount of data that was read or written. Several logical requests can be
combined into one physical request.
Flags
Note: Both the -f and -s flags can be entered on the command line, but the
system will only accept the first flag specified and override the second flag.
-f Reports the number of forks since system startup.
-i Displays the number of interrupts taken by each device since system startup.
-s Writes to standard output the contents of the sum structure, which contains an

157
absolute count of paging events since system initialization. The -s option is
exclusive of the other vmstat command options. These events are described as
follows:
address translation faults
Incremented for each occurrence of an address translation page fault. I/O may or
may not be required to resolve the page fault. Storage protection page faults (lock
misses) are not included in this count.
page ins
Incremented for each page read in by the virtual memory manager. The count is
incremented for page ins from page space and file space. Along with the page out
statistic, this represents the total amount of real I/O initiated by the virtual
memory manager.
page outs
Incremented for each page written out by the virtual memory manager. The count
is incremented for page outs to page space and for page outs to file space. Along
with the page in statistic, this represents the total amount of real I/O initiated by
the virtual memory manager.
paging space page ins
Incremented for VMM initiated page ins from paging space only.
paging space page outs
Incremented for VMM initiated page outs to paging space only.
total reclaims
Incremented when an address translation fault can be satisfied without initiating a
new I/O request. This can occur if the page has been previously requested by
VMM, but the I/O has not yet completed; or if the page was pre-fetched by VMM's
read-ahead algorithm, but was hidden from the faulting segment; or if the page
has been put on the free list and has not yet been reused.
zero-filled page faults
Incremented if the page fault is to working storage and can be satisfied by
assigning a frame and zero-filling it.
executable-filled page faults

Incremented for each instruction page fault.
pages examined by the clock
VMM uses a clock-algorithm to implement a pseudo least recently used (lru) page

158
replacement scheme. Pages are aged by being examined by the clock. This count
is incremented for each page examined by the clock.
revolutions of the clock hand
Incremented for each VMM clock revolution (that is, after each complete scan of
memory).
pages freed by the clock
Incremented for each page the clock algorithm selects to free from real memory.
backtracks
Incremented for each page fault that occurs while resolving a previous page fault.
(The new page fault must be resolved first and then initial page faults can be
backtracked.)
lock misses
VMM enforces locks for concurrency by removing address ability to a page. A page
fault can occur due to a lock miss, and this count is incremented for each such
occurrence.
free frame waits
Incremented each time a process is waited by VMM while free frames are
gathered.
extend XPT waits
Incremented each time a process is waited by VMM due to a commit in
progress for the segment being accessed.
pending I/O waits
Incremented each time a process is waited by VMM for a page-in I/O to
complete.
start I/Os
Incremented for each read or write I/O request initiated by VMM. This
count should equal the sum of page-ins and page-outs.
iodones
Incremented at the completion of each VMM I/O request.
CPU context switches
Incremented for each CPU context switch (dispatch of a new process).
device interrupts
Incremented on each hardware interrupt.
software interrupts
Incremented on each software interrupt. A software interrupt is a machine

159
instruction similar to a hardware interrupt that saves some state and branches to
a service routine. System calls are implemented with software interrupt
instructions that branch to the system call handler routine.
traps
Not maintained by the AIX operating system.
syscalls
Incremented for each system call.
Examples
1. To display a summary of the statistics since boot, enter:
vmstat
2. To display five summaries at 2-second intervals, enter:
vmstat 2 5
The first summary contains statistics for the time since boot.
3. To display a summary of the statistics since boot including statistics for logical
disks scdisk13 and scdisk14, enter:
vmstat scdisk13 scdisk14
4. To display fork statistics, enter:
vmstat -f
5. To display the count of various events, enter:
vmstat –s
Files
/unix Symbolic link to the kernel boot image.
/usr/bin/vmstat Contains the vmstat command.
iostat Command

160
Purpose
Reports the CPU and I/O Statiscs for tty devices, disks and CDROM’s.
Syntax:
iostat [ -d | -t ] [ PhysicalVolume ... ] [ Interval [ Count ] ]
Description:
The iostat command is used for monitoring system input/output device loading by
observing the time the physical disks are active in relation to their average transfer
rates. The iostat command generates reports that can be used to change system
configuration to better balance the input/output load between physical disks.
The first report generated by the iostat command provides statistics concerning the
time since the system was booted. Each subsequent report covers the time since the
previous report. All statistics are reported each time the iostat command is run. The
report consists of a tty and CPU header row followed by a row of tty and CPU
statistics. On multiprocessor systems, CPU statistics are calculated system-wide as
averages among all processors. A disks header row is displayed followed by a line of
statistics for each disk that is configured. If the PhysicalVolume parameter is
specified, only those names specified are displayed.
If the PhysicalVolume parameter is specified, one or more alphabetic or

alphanumeric physical volumes can be specified. If the PhysicalVolume parameter is
specified, the tty and CPU reports are displayed and the disk report contains
statistics for the specified drives. If a specified logical drive name is not found, the
report lists the specified name and displays the message Drive Not Found. If no
Logical Drive Names are specified, the report contains statistics for all configured
disks and CD-ROMs. If no drives are configured on the system, no disk report is
generated. The first character in the PhysicalVolume parameter cannot be numeric.
The Interval parameter specifies the amount of time in seconds between each report.
The first report contains statistics for the time since system startup (boot). Each
subsequent report contains statistics collected during the interval since the previous
report. The Count parameter can be specified in conjunction with the Interval
parameter. If the Count parameter is specified, the value of count determines the
number of reports generated at Interval seconds apart. If the Interval parameter is

161
specified without the Count parameter, the iostat command generates reports
continuously.
The iostat command is useful in determining whether a physical volume is becoming

a performance bottleneck and if there is potential to improve the situation. The %
utilization field for the physical volumes indicates how evenly the file activity is
spread across the drives. High % utilization on a physical volume is a good indication
that there may be contention for this resource. Since the CPU utilization statistics are
also available with the iostat report, the percentage of time the CPU is in I/O wait
can be determined at the same time. Consider distributing data across drives if the
I/O wait time is significant and the disk utilization is not evenly distributed across
volumes.
Note: Some system resource is consumed in maintaining disk I/O history for
the iostat command. Use the sysconfig subroutine, or the System
Management Interface Tool (SMIT) to stop history accounting.
Reports
The iostat command generates two types of reports, the tty and CPU Utilization
report and the Disk Utilization report.
tty and CPU Utilization Report
The first report generated by the iostat command is the tty and CPU Utilization
Report. For multiprocessor systems, the CPU values are global averages among all
processors. Also, the I/O wait state is defined system-wide and not per processor.
The report has the following format:
Column Description
tin Shows the total number of characters read by the system for all ttys.
tout Shows the total number of characters written by the system to all ttys.
% user Shows the percentage of CPU utilization that occurred while executing at
the user level (application).
% sys Shows the percentage of CPU utilization that occurred while executing at
the system level (kernel).

162
% idle Shows the percentage of time that the CPU or CPUs were idle and the
system did not have an outstanding disk I/O request.
% iowait Shows the percentage of time that the CPU or CPUs were idle during which
the system had an outstanding disk I/O request. This value may be slightly
inflated if several processors are idling at the same time, an unusual
occurrence.
This information is updated at regular intervals by the kernel (typically sixty times
per second). The tty report provides a collective account of characters per second
received from all terminals on the system as well as the collective count of
characters output per second to all terminals on the system.
Disk Utilization Report
The second report generated by the iostat command is the Disk Utilization Report.
The disk report provides statistics on a per physical disk basis. The report has a
format similar to the following:
% tm_act Indicates the percentage of time the physical disk was active (bandwidth
utilization for the drive).
Kbps Indicates the amount of data transferred (read or written) to the drive in
KB per second.
tps Indicates the number of transfers per second that were issued to the
physical disk. A transfer is an I/O request to the physical disk. Multiple
logical requests can be combined into a single I/O request to the disk. A
transfer is of indeterminate size.
Kb_read The total number of KB read.
Kb_wrtn The total number of KB written.
Statistics for CD-ROM devices are also reported.
For large system configurations where a large number of disks are configured, the
system can be configured to avoid collecting physical disk input/output statistics
when the iostat command is not executing. If the system is configured in the above
manner, the first Disk report displays the message Disk History Since Boot Not

163
Available instead of the disk statistics. Subsequent interval reports generated by the
iostat command contain disk statistics collected during the report interval. Any tty
and CPU statistics after boot are unaffected. If a system management command is
used to re-enable disk statistics keeping, the first iostat command report displays
activity from the interval starting at the point that disk input/output statistics were
enabled.
Flags
-d The -d option is exclusive of the -t option and displays only the disk utilization
report.
-t The -t option is exclusive of the -d option and displays only the tty and cpu usage
reports.
Examples
1. To display a single history since boot report for all tty, CPU, and Disks, enter:
iostat
2. To display a continuous disk report at two second intervals for the disk with
the logical name disk1, enter:
iostat -d disk1 2
3. To display six reports at two second intervals for the disk with the logical
name disk1, enter:
iostat disk1 2 6
4. To display six reports at two second intervals for all disks, enter:
iostat -d 2 6
5. To display six reports at two second intervals for three disks named disk1,
disk2, disk3, enter:
iostat disk1 disk2 disk3 2 6

164
Netstat
netstat is a useful tool for checking your network configuration and activity. It is in
fact a collection of several tools lumped together. We discuss each of its functions in
the following sections.
Displaying the Routing Table
When you invoke netstat with the –r flag, it displays the kernel routing table in the
way we've been doing with route. On vstout, it produces:
# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
127.0.0.1 * 255.255.255.255 UH 00 0 lo
172.16.1.0 * 255.255.255.0 U 00 0 eth0
172.16.2.0 172.16.1.1 255.255.255.0 UG 00 0 eth0
The –n option makes netstat print addresses as dotted quad IP numbers rather than
the symbolic host and network names. This option is especially useful when you want
to avoid address lookups over the network (e.g., to a DNS or NIS server).
The second column of netstatԜ's output shows the gateway to which the routing
entry points. If no gateway is used, an asterisk is printed instead. The third column
shows the “generality” of the route, i.e., the network mask for this route. When
given an IP address to find a suitable route for, the kernel steps through each of the
routing table entries, taking the bitwise AND of the address and the genmask before
comparing it to the target of the route.
The fourth column displays the following flags that describe the route:
G The route uses a gateway.
U The interface to be used is up.
H Only a single host can be reached through the route. For example, this is the
case for the loop back entry 127.0.0.1.

165
D This route is dynamically created. It is set if the table entry has been generated
by a routing daemon like gated or by an ICMP redirect message
M This route is set if the table entry was modified by an ICMP redirect message.
! The route is a reject route and datagrams will be dropped.
The next three columns show the MSS, Window and irtt that will be applied to TCP
connections established via this route. The MSS is the Maximum Segment Size and is
the size of the largest datagram the kernel will construct for transmission via this
route. The Window is the maximum amount of data the system will accept in a single
burst from a remote host. The acronym irtt stands for “initial round trip time.” The
TCP protocol ensures that data is reliably delivered between hosts by retransmitting
a datagram if it has been lost. The TCP protocol keeps a running count of how long it
takes for a datagram to be delivered to the remote end, and an acknowledgement to
be received so that it knows how long to wait before assuming a datagram needs to
retransmitted; this process is called the round-trip time. The initial round-trip time is
the value that the TCP protocol will use when a connection is first established. For
most network types, the default value is okay, but for some slow networks, notably
certain types of amateur packet radio networks, the time is too short and causes
unnecessary retransmission. The irtt value can be set using the route command.
Values of zero in these fields mean that the default is being used.
Finally, the last field displays the network interface that this route will use.

166
Displaying Interface Statistics
When invoked with the –i flag, netstat displays statistics for the network interfaces
currently configured. If the –a option is also given, it prints all interfaces present in
the kernel, not only those that have been configured currently. On vstout, the output
from netstat will look like this:
# netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR
Flags
lo 0 0 3185 0 0 0 3185 0 0 0 BLRU
eth0 1500 0 972633 17 20 120 628711 217 0 0 BRU
The MTU and Met fields show the current MTU and metric values for that interface.
The RX and TX columns show how many packets have been received or transmitted
error-free (RX-OK/TX-OK) or damaged (RX-ERR/TX-ERR); how many were dropped
(RX-DRP/TX-DRP); and how many were lost because of an overrun (RX-OVR/TX-
OVR).
The last column shows the flags that have been set for this interface. These
characters are one-character versions of the long flag names that are printed when
you display the interface configuration with ifconfig:
B A broadcast address has been set.

L This interface is a loopback device.
M All packets are received (promiscuous mode).
O ARP is turned off for this interface.
P This is a point-to-point connection.
R Interface is running.
U Interface is up.

167
Displaying Connections
netstat supports a set of options to display active or passive sockets. The options –
t, –u, –w, and –x show active TCP, UDP, RAW, or Unix socket connections. If you
provide the –a flag in addition, sockets that are waiting for a connection (i.e.,
listening) are displayed as well. This display will give you a list of all servers that are
currently running on your system. Invoking netstat -ta on vlager produces this
output:
$ netstat -ta
Active Internet Connections
Proto Recv-Q Send-Q Local Address Foreign Address (State)
tcp 0 0 *:domain *:* LISTEN
tcp 0 0 *:time *:* LISTEN
tcp 0 0 *:smtp *:* LISTEN
tcp 0 0 vlager:smtp vstout:1040 ESTABLISHED
tcp 0 0 *:telnet *:* LISTEN
tcp 0 0 localhost:1046 vbardolino:telnet ESTABLISHED
tcp 0 0 *:chargen *:* LISTEN
tcp 0 0 *:daytime *:* LISTEN
tcp 0 0 *:discard *:* LISTEN
tcp 0 0 *:echo *:* LISTEN
tcp 0 0 *:shell *:* LISTEN
tcp 0 0 *:login *:* LISTEN
This output shows most servers simply waiting for an incoming connection. However,
the fourth line shows an incoming SMTP connection from vstout, and the sixth line
tells you there is an outgoing telnet connection to vbardolino.
Using the –a flag by itself will display all sockets from all families.
Notes
You can tell whether a connection is outgoing from the port numbers. The port
number shown for the calling host will always be a simple integer. On the host being
called, a well-known service port will be in use for which netstat uses the symbolic
name such as smtp, found in /etc/services.
168
lockstat
Displays simple and complex lock contention information.
Syntax
lockstat [ -a ][ -c LockCount ] [ -b BlockRatio ] [ -n CheckCount ] [ -p LockRate ]
[ -t MaxLocks ] [ Interval [Count ] ]
Description
Note: To enable lock statistics collection, the bosboot -L command must be

executed.
The lockstat command reports statistics about contention in the operating system
among simple and complex kernel locks. Reports generated by the lockstat
command can be used to ensure that system performance is not being reduced by
excessive lock contention.
The lockstat command generates a report for each kernel lock, which meets all the
specified conditions. If no condition values are specified, default conditions are used.
The reports give information about the number of lock requests for each lock. A lock
request is a lock operation (such as taking or upgrading a lock), which in some cases
cannot be satisfied immediately. A lock request, which cannot be satisfied at once, is
said to block. A blocked request will either spin (repeatedly execute instructions
which do nothing) or sleep (allowing another thread to execute).
The column headings in the lockstat command listing have the following meanings:
Subsys The subsystem to which the lock belongs.
Name The symbolic name of the lock class.
Ocn The occurrence number of the lock in its class.
Ref/s The reference rate, or number of lock requests per second.
%Ref The reference rate expressed as a percentage of all lock requests.
%Block The ratio of blocking lock requests to total lock requests. A block occurs

169
whenever the lock cannot be taken immediately.
%Sleep The percentage of lock requests that cause the calling thread to sleep.
Flags
-a Displays a supplementary list showing the most requested (or active)

locks, regardless of the conditions defined by other flags.
-c LockCount Specifies how many times a lock must be requested during an

interval in order to be displayed. The default value of the LockCount
parameter is 200.
-b BlockRatio Specifies a block ratio. A lock must have a block ratio that is higher
than the specified BlockRatio parameter in order to be listed. The
default value of the BlockRatio parameter is five percent.
-n CheckCount Specifies the number of locks that are to be checked. The lockstat
command sorts locks according to lock activity. The CheckCount
parameter determines how many of the most active locks will be
subject to further checking. Limiting the number of locks that are
checked maximizes system performance, particularly if the Count
parameter is used to run the lockstat command repeatedly. By
default, the 40 most active locks are checked.
-p LockRate Specifies a percentage of the activity of the most-requested lock in

the kernel. Only locks that are more active than this will be listed.
The default LockRate value is two, meaning that the only locks listed
are those requested at least two percent as often as the most active
lock. Note that LockRate is not the same concept as the %Ref field,
which is relative to the total number of lock requests.
-t MaxLocks Specifies the maximum number of locks to be displayed. The default

is to list up to 10 locks.

170
Parameters
Interval Specifies the amount of time in seconds between each report. Each report
contains statistics collected during the interval since the previous report. If
the Interval parameter is not specified, the lockstat command generates a
single report covering an interval of one second and then exits.
Count Determines the number of reports generated. The Count parameter can only
be specified with the Interval parameter. If the Interval parameter is
specified without the Count parameter, reports are continuously generated.
A Count parameter of 0 is not allowed./TD>
Examples
1. To generate a single lock statistic report based on default conditions, enter:
lockstat
The output is similar to:
Subsys Name Ocn Ref/s %Ref %Block %Sleep

-----------------------------------------------------------------
PROC PROC_LOCK_CLASS 2 1442 3.06 6.98 0.75
PROC PROC_INT_CLASS 1 1408 2.98 5.86 1.77
IOS IOS_LOCK_CLASS 4 679 1.44 5.19 2.29
2. To generate 100 lock statistic reports at one second intervals, displaying only
those locks which are more than 50 percent as active as the most active lock,
enter:
3. lockstat -p
50 1 100
File
/usr/bin/lockstat Contains the lockstat command.

171
mpstat
mpstat - Report processors related statistics.
Syntax:
mpstat [ -P { cpu | ALL } ] [ -V ] [ interval [ count ] ]
Description
The mpstat command writes to standard output activities for each available
processor, processor 0 being the first one. Global average activ ities among all
processors are also reported. The mpstat command can
be used both on SMP and UP machines, but in the latter, only global average
activities will be printed.
The interval parameter specifies the amount of time in seconds between each
report. A value of 0 indicates that processors statistics are to be reported for the
time since system startup (boot). The count parameter can be specified in
conjunction with the interval parameter if this one is not set to zero. The value of
count determines the number of reports generated at interval seconds apart. If the
interval parameter is specified without the count parameter, the mpstat command
generates reports continuously.
Reports
The report generated by the mpstat command has the following format:
CPU
Processor number. The keyword all indicates that statistics are calculated as
averages among all processors.
%user
Show the percentage of CPU utilization that occurred while executing at the user
level (application).
%nice
Show the percentage of CPU utilization that occurred while executing at the user
level with nice priority.

172
%system
Show the percentage of CPU utilization that occurred while executing at the system
level (kernel). Note that this does not include the time spent servicing interrupts or
softirqs.
%iowait
Show the percentage of time that the CPU or CPUs were idle during which the
system had an outstanding disk I/O request.
%irq
Show the percentage of time spent by the CPU or CPUs to service interrupts.
%soft
Show the percentage of time spent by the CPU or CPUs to service softirqs. A
softirq (software interrupt) is one of up to 32 enumerated software interrupts
which can run on multiple CPUs at once.
%idle
Show the percentage of time that the CPU or CPUs were idle and the system did not
have an outstanding disk I/O request.
intr/s
Show the total number of interrupts received per second by the CPU or CPUs.
Options
-P cpu | ALL
Indicate the processor number for which statistics are to be reported. cpu is the
processor number. Note that processor 0 is the first processor. The ALL keyword
indicates that statistics are to be reported for all processors.
-V Print version number and usage then exit.

173
Environment
The mpstat command takes into account the following environment variable:
S_TIME_FORMAT
If this variable exists and its value is ISO then the current locale will be ignored
when printing the date in the report header. The mpstat command will use the ISO
8601 format (YYYY- MM-DD) instead.
EXAMPLES
mpstat 2 5
Display five reports of global statistics among all processors at two-second intervals.
mpstat -P ALL 2 5
Display five reports of statistics for all processors at two-second intervals.
BUGS
/proc file system must be mounted for the mpstat command to work.
Only the Linux kernel for each processor supplies a few activities.
FILES
/proc contains various files with system statistics.
References:
1) Mercury Support site (http://support.mercury.com) knowledge base and
discussion forum.
2) LoadRunner 8.1 and 9.0 Manual.
3) http://www.wilsonmar.com/1loadrun.htm
4) Load Runner Yahoo group
http://groups.yahoo.com/group/LoadRunner/
5) Advanced LoadRunner Yahoo Group
http://groups.yahoo.com/group/Advanced-LoadRunner/

174
The TCP/IP network architecture

TCP/IP is a shorthand for the two most important protocols used to make the
internet work .The internet protocol (IP) is responsible for transferring these data
packets while the transmission control protocol makes sure all packets arrive safely,
retransmitting them if necessary, an alternative to TCP is the user data gram
protocol (UDP), which is unreliable but fast protocol that is often used for data
transfer.
The internet architecture is made of five layers that work together .these five layers
are from high to low.
1. The application layer

2. The Transport Layer
2. The Network Layer
3. The Link Layer
4. The Physical Layer
THE APPLICATION LAYER
The application layer defines how certain services operate and how they can be used.
Examples are the FTP service for transferring files, HTTP for serving Web pages and
SMTP for e-mail.
These services are defined in a rather abstract manner. Two parties, called the client
and the server, set up a connection over which they exchange messages in
accordance with a specific protocol. The client starts the protocol by requesting the
service. Often the next step is for the server to authenticate the client, for example
by asking for a password or by executing a public-key based protocol.
Taking e-mail as an example, the protocol in question is called the Simple Mail
Transfer Protocol (SMTP). The client and the server set up an SMTP connection over
which they exchange identifying information. The client then tells who the message
is from and who the intended recipient is. The server then indicates whether it
accepts or refuses the message (for example if its spam or the intended recipient is
unknown). If the message is accepted, the client sends the actual content of the
message and the server stores it in the right mailbox.

175
The Transport Layer
On the Internet, the transport layer is realized by two protocols. The first is the
Transmission Control Protocol (TCP) and the second is the User Datagram Protocol
(UDP). Both break up a message that an application wants to send into packets and
attempt to deliver those packets to the intended recipient. At the recipient's side,
both take the payload from the received packets and pass those to the application
layer.
The main difference between TCP and UDP is that TCP is reliable and UDP is not. TCP
will collect incoming packets, put them in the right order and thereby reassemble the
original message. If necessary, TCP requests retransmission of lost or damaged
packets. UDP merely takes each incoming packet and delivers the payload (the
original message) to the application layer. Any errors or out-of-order data should be
taken care of by the application.
UDP is much faster than TCP, and so is mainly used for applications like audio and
video streaming, where the occasional error is less important than getting all the
data there at the right time. More generally, UDP is designed for applications that do
not require the packets to be in any specific order. Because of this, UDP is
sometimes called a "connection-less" protocol.
Taking the example of e-mail again, the e-mail client and server communicate over a
reliable TCP connection. The server listens on a certain port (port 25) until a
connection request arrives from the client. The server acknowledges the request, and
a TCP connection is established. Using this connection the client and server can
exchange data.
The content of this data is not really relevant at this level: that's the responsibility of
the application layer. The e-mail message and all the other information exchanged at
that SMTP application layer are merely payload, data that needs to be transported.
Hence the name transport layer.

176
The Network Layer
The network layer is responsible for transmitting and routing data packets over the
network. The Internet uses the Internet Protocol or IP as its network layer. Each
node on the network has an address, which of course is called the IP address. Data is
sent as IP packets.
A transport layer connection is made up up of a large number of IP packets

exchanged by the client and server. The Internet Protocol (IP) is very simple: a
packet has a source, a destination and a payload, and it's passed from one node in
the network to another until it gets to the destination. The IP does not notice that a
packet gets lost. It just never gets to the destination. If a particular node cannot
pass the packet to the next node along the normal route, it will do its best to find an
alternative path. That's why IP is sometimes called a "best-effort" protocol.
When the client sends its TCP connection request, the network layer puts the request
in a number of packets and transmits each of them to the server. Each packet can
take a different route, and some of the packets may get lost along the way. If they
all make it, the transport layer at the server is able to reconstruct the request, and it
will prepare a response confirming that a TCP connection has been set up. This
response is sent back again in a number of IP packets that will hopefully make it to
the client.
The Link Layer
The Internet Protocol basically assumes all computers are part of one very large
"web" of nodes that can all pass packets to other nodes. There's always a route from
one node to another, even if sometimes a very large number of intermediate nodes
get involved. The link layer is what makes this assumption true.
The link layer provides a network connection between hosts on a particular local
network, as well as interconnection between such local networks. The e-mail client
runs on a personal computer in someone's home network, which is set up using the
Ethernet protocol. The link layer now is that Ethernet network. The IP packets that
this computer transmits are added as payload to Ethernet packets (called "frames")
that are transmitted over the local network to the ADSL modem that connects the
local network to the provider.

177
A different kind of link layer protocol is used to transmit the payload taken from the
Ethernet frames from the ADSL modem to the provider. At the provider this payload
is again passed forward using yet another link level protocol. The "web of nodes"
that the Internet Protocol relies on thus actually is made up of a large number of
local networks, each with their own link layer protocol, that each forward the IP
packet by putting it into their own kind of message that is then sent over the local
network.
Physical Layer
The lowest layer is the physical layer, which defines how the cables, network cards,
wireless transmitters and other hardware connect computers to networks and
networks to the rest of the Internet. Examples of physical layer networks are
Ethernet, WiFi, Token Ring and Fiber Data Distributed Interface (FDDI). Note that
many of these technologies also have their own link layer protocol. Often link and
physical layer are closely related.
The physical layer provides the means to transfer the actual bits from one computer
to another. In an Ethernet network (a link layer protocol); a computer is connected
by plugging a network cable into its Ethernet card, and then plugging the other end
of that cable into a router or switch. The physical layer specifies how bits of data are
sent over that cable: how do the electrical currents or the pulses the card sends get
turned back into the data for the higher level layers. For wireless networks, this
works exactly the same, except of course there is no cable.
Putting the layers together
Higher layers rely on lower layers
Each layer relies on the layer below it for the actual transmission of data, adding or
providing specific functionality for its own intended purpose. The link layer relies on a
network cable over which Ethernet packets can be sent. The network layer uses
these Ethernet packets to transport IP packets, and adds the ability to route the
packets across networks. The transport layer relies on IP packets to create and
establish the TCP connection, or to transport UDP packets.

178
TCP adds reliability by keeping track of the data sent in the IP packets and
retransmitting them if they are lost. And finally applications use TCP or UDP
connections to exchange the data that makes up the application protocol: logging in
to servers, requesting and transmitting Web pages, delivering e-mail, and so on.
Lower layers encapsulate higher-layer data
At every layer certain messages are exchanged. Each message at a particular level
contains as payload all or part of a message that a higher layer wants to send. This
is called data encapsulation.
For example, a Web browser (an application) needs to send a request for a Web
page to a server. This request is passed on to the transport layer, which sets up a
connection to port 80 of the server and transmits a TCP message containing the
request. The server responds with a TCP message containing the response.
Embedded in the response is the Web page itself. The TCP layer strips off the
response and passes the payload, the Web page, to the browser which then renders
it.
The TCP request and response are both transmitted by the IP layer. The TCP layer
breaks them up into parts that get put in different IP packets. A sequence number is
added to each part, allowing the receiving TCP layer to re-assemble the parts and
thereby recover the actual message. If IP packets are received out of order, the
receiving TCP layer can re-order them. Any missing packets can also be detected.
The receiving TCP layer will then request retransmission.
The IP packets are then put into Ethernet frames or other link-layer messages. If
necessary the IP packets are again divided up into parts, each of which is put into
different link-layer messages. The receiving link layer then re-assembles the IP
packet and passes it to the network layer.
At the physical level, the Ethernet frames are turned into a series of ones and zeroes
in the form of electrical currents or pulses that are transmitted over the network
cable or through the air.
Layers have specific addressing schemes

179
Every layer uses its own addressing scheme. At the application level for example, the
SMTP e-mail service runs on what's called port 25 of the server. The server has its IP
address, which the network layer uses to get the IP packets to the server. Each
network in between uses its own link layer addresses. For example in an Ethernet
network every computer or network card has a 12-byte MAC address. With this
address, other devices on an Ethernet network can send data to that device.

180
The Internet's basic protocols: TCP/IP
The TCP/IP protocols are the core protocols that make up the Internet. The packet
based design of TCP/IP has made the Internet very resilient packets.
The term ‘TCP?IP’ is both a general name for the Internet architecture as well as an
abbreviation of the two most important protocols in that architecture .The internet is
based on packet based data transmission. Data is divided into packets that are
transported individually from computer to computer and from network to network.
Each computer on the has its own IP address that is used to transfer the these
TCP/IP architecture

181
HTTP FTP DNS
Telnet Finger SSH SNMP
DNS RIP
Application
OP3/IMAP SMTP ADIUS
Layer ng
Gopher BGP Archie
ime/NTP Who is race route
TACACS+ SSL ftp
Transport
CP DP CMP SPF
Layer
Internet
P RP
Layer
Ethernet/802.3 Token Ring (802.5)

SNAP/802.2 X.25 FDDI ISDN
rame Relay SMDS ATM Wireless (WAP, CDPD,
Network
02.11)
Interface Layer
iber Channel DDS/DS0/T-carrier/E-carrier
SONET/SDH DWDM
PP HDLC SLIP/CSLIP xDSL Cable Modem
DOCSIS)
FIGURE 2. Abbreviated TCP/IP protocol stack.
TCP/IP networking basics: hubs, switches, gateways and routing
TCP/IP networks are the most common type of network today. With such network, a
number of computers or nodes can communicate with each other. An important
aspect of this communication is routing. Getting data packets from one node to
another, in particular from one node on one network to another node on another
network.
Nodes, hubs and switches
A network is a collection of computers or other devices, commonly called nodes that

are able to communicate with each other. This communication takes place on
different network levels. A network may use the Internet Protocol (IP) at one level

182
and Ethernet at the level directly below it. This distinction is important because some
parts of the network operate at the IP level and others at the Ethernet level.
The most common type of network (especially in the home) is the Ethernet network
shown in figure 1, where all nodes are connected to a central device. In its simplest
form this central node is called a hub.
Figure 1: a basic network architecture
Basically, a hub is a box with lots of connections (sockets) for Ethernet cables. The
hub repeats all messages it receives to all connected nodes, and these nodes filter
out only the messages that are intended for them. This filtering takes place at the
Ethernet level: incoming messages carry the Ethernet network address of the
intended recipient.
A problem with this approach is that hubs generate a lot of traffic, especially on
larger networks. Most of this traffic is wasted, since it is intended for only one node
but it is sent to all nodes on the network.

183
Figure 2: a basic network with a hub and a switch
A commonly used solution today is a switch. A switch still connects all nodes to each
other, like a hub, but is more intelligent in which messages are passed on to which
node. A switch examines incoming Ethernet messages to see which node is the
intended recipient, and then directly (and only) passes the messages to that node.
This way other nodes do not unnecessarily receive all traffic.
Since switches are more expensive than hubs, a low-traffic part of the network could be
set up using a hub, with the more high-traffic nodes being interconnected to the switch.
The hub segment is then connected to the switch as well, as shown in figure 2.
Segments and bridges
A large network can be divided into multiple parts which are called segments. Each
segment can use its own network protocol, security rules, and firewalls and so on.
Nodes on different segments cannot directly communicate with each other. To make
this possible, a bridge is added between the segments, as shown in figure 3.
Figure 3: two network segments connected via a bridge
The bridge lets packet pass that are destined for a host on the other side. This seems to
turn the two segments into one big network again, but there is an important difference.
Data packets generated on one segment and intended for that same segment are not
passed to the other segment. This saves on data transmission on the network as a whole.
Routers and routing

184
Figure 4: two networks connected via a router
The above examples all presented a single network at the Internet Protocol level.
Even when the network is segmented, all nodes are still able to communicate with
each other. To connect networks, a router or gateway is used.
Routers and gateways
A router is connected to two different networks and passes packets between them,
as shown in figure 4 to the right. In a typical home network, the router provides the
connection between the network and the Internet.
A gateway is the same as a router, except in that it also translates between one network
system or protocol and another. The NAT protocol for example uses a NAT gateway to
connect a private network to the Internet.
Routing messages between networks
When a node on one network needs to send a message to a node on another

network, this packet will be picked up by the router and passed on to the other
network. Many nodes are programmed with a so-called 'default gateway', which is
the address of the router that is to take care of all packets not for other nodes on the
same network.

185
Routers maintain a so-called routing table to keep track of routes: which
connections (to different networks) are to be used for which faraway networks. Some
of these routes are programmed in manually, but many are "learned" automatically
by the router. Modern routers inform each other about new routes and no longer
working routes to make this as efficient as possible.
Figure 5 below illustrates how routers (and behind them, entire networks) may be
connected. There are now multiple routes from the node at the left to the node at
the right. Since routers transmit IP packets, and IP packets are all independent of
one another, each packet can travel along a different route to its destination.
The TCP protocol that runs in the transport layer above does not notice this,
although a user may notice if suddenly the connection seems faster or slower. That
could be caused by packets now following a different route that is faster or slower
than the old one.
Figure 5: how two nodes on different networks can communicate

with each other
Security of routing
Routing data packets in this way is very efficient, but not very secure. Every router
in between the source and the destination can examine every packet that comes
through. This enables for example systems like Carnivore (in Dutch) to examine
almost all Internet traffic. Using encrypted Internet transmissions avoids this.

186
An additional risk is traffic analysis. A router can see where packets come from and
where they go to. Even if the content of the packets is encrypted, the source or
destination address itself already reveals something about the communication. For
example, a corporate IP address that sends data to a newspaper website may
indicate leaking of business secrets.
Onion routing with systems like T or avoid even this risk, although they are much
slower than traditional routing systems

187
Internet Protocol (IP) addresses
The internet protocol transmits packets from one node on an IP network to another.
This requires that both nodes have their own unique address: the IP address. There
are two versions of IP: version 4 and version 6 .In the past IP addresses version 4
were managed using lasses but now, especially with IP version 6, classes addressing
is used more often.
Certain addresses are defined as for local use only; such private networks cannot
communicate with the rest of the internet directly. The network addresses translation
(NAT) scheme is used to allow such network access to the public internet.
IP address structure
On Internet Protocol (IP) networks such as the Internet itself, data is sent in packets.
Each packet carries the addresses of the source and the destinations. These
addresses on IP networks are then of course called IP addresses. Every node
(computer) on an IP network needs to have its own IP address.
As humans usually prefer to use names, applications such as Web browsers will need
to translate those names (using DNS) into IP addresses before they can
communicate with the host in question.
IP version 4 addresses
IP version 4 (IPv4) is the main version of the Internet Protocol. This version is
currently used by almost all IP networks. An IP version 4 addresses is a 32-bit
number that is typically written as four decimal numbers separated by periods. An
example is "192.168.1.3".
As a convention, an IP address that ends in ".1" usually refers to a gateway or router

on a particular network. An address that ends in ".255" is a so-called broadcast
address: all devices in the same network should handle packets addressed to the
broadcast address.

188
IP version 6 addresses
IP version 6 (IPv6) addresses were introduced because the old IP version 4 addresses
were in danger of running out. An IP version 6 address is a 128-bit number that is
typically written as eight groups of four hexadecimal digits. The groups are separated by
colons. An example is "2001:610:113b:50a1: 136".
Class-based IP addresses
Originally, when the Internet Protocol was first defined, IP (version 4) addresses
were handed out to organizations in blocks. There are three classes of blocks: Class
A, Class B and Class C. The higher the class, the larger the number of IP addresses
in the block.
The class an IP address belongs to follows from the first decimal number: Class A
addresses have numbers between 1 and 127, Class B is between 128 and 191, and
Class C is 192 and higher. There are also Class D (224 to 247) and Class E (248-
255), but these are rarely used in practice.
The organization is itself responsible for dividing the IP addresses in its assigned
block to nodes in its IP network. For example, the Windhaven University of
Technology has been assigned the Class B block of 131.155, and so can use any IP
address between 131.155.0.1 and 131.155.255.254. The ".0.0" and ".255.255"
addresses are reserved.
It's clear that this method of dividing up the IP address blocks quickly runs out of
addresses. A Class B and especially a Class A block gives an enormous amount of
addresses to one organization, which probably does not need all of them. However the
remaining unneeded parts of the block cannot be reassigned to someone else.
Classless IP addresses
To allow a more fine-grained way of handing out addresses, today most IP version 4
address blocks are handed out as subnets. This approach avoids the class-based
division and its coarse-grained distribution of IP addresses. For IPv6, classless
assignment is the only way to obtain blocks of IP version 6 addresses.

189
Subnets
A block of IP addresses can be divided into smaller, more manageable groups that
can each be assigned to different organizations. And even within one organization
different subnets can be set up for different networks within the organization.
For example every building could be given its own subnet, or the sales, marketing
and R&D departments could be given their own respective subnets. The subnets or
local networks can then be managed separately, for example with their own firewalls
or separate connections to the Internet.
Subnet masks
Subnets are defined by means of a subnet mask that specifies which parts of an IP
address belong to the group, the network, and which parts make up the individual
node's address. This requires comparing the IP address and the subnet mask (or just
net mask for short) in their binary forms. If a bit of the subnet mask is '1', the
corresponding bit in the IP address belongs to the group (subnet). If the subnet bit is
'0', the corresponding IP address bit is part of the individual address.
An example: subnetting a Class B netblock
For example, consider the IP address "192.168.100.1". This is part of the Class B
block "192.168". The standard subnet mask in this block is "255.255.0.0", which
means there are 65,000 individual IP addresses in this network (these range from
192.168.0.1 to 192.168.255.254). To split this up, the network administrator can
define the subnet mask "255.255.255.0", which allows the creation of 255 networks
with 255 hosts in each network. More flexibility can be obtained with more creative
choices of subnets.
Default network
The default subnet mask is "255.255.255.0". This makes the IP address

"192.168.100.1" a part of the network "192.128.100.*". This is determined by
comparing bits in the IP address and the subnet mask, as shown in the below table:

190
Decimal address: 192 . 168 . 100 . 1
Address in binary: 11000000 10101000 01100100 00000001
Binary netmask: 11111111 11111111 11111111 00000000
Network address: 11000000 10101000 01100100 00000000
Address in decimal: 192 . 168 . 100 . 0
The zero at the end indicates that this is a network address. This is why individual
hosts can only have IP addresses ending in 1 or higher.
Changing the subnet mask
The same address can belong to a different network by changing the subnet mask.
For example, when the subnet mask is "255.255.240.0" instead, the network
address now is "192.168.96.*":
Decimal address: 192 . 168 . 100 . 1

Address in binary: 11000000 10101000 01100100 00000001
Binary netmask: 11111111 11111111 11110000 00000000
Network address: 11000000 10101000 01100000 00000000
Address in decimal: 192 . 168 . 96 . 0
This choice of netmask allows 4,095 hosts on a single network, although only 16 of
these networks can be created within this block of IP addresses. The fact that this
network has the number '96' in its third decimal is misleading: it's actually the sixth
network (decimal six in binary is 0110), but because of the four zeroes after the
"0110" in the notation above, the third decimal in the IP address becomes "96".
Of course an administrator can use different subnets within one block. This way one
network can have 255 nodes and another can have 4,095 hosts. The netmasks should be
chosen carefully not to overlap each other of course.
Reserved addresses
Not everyone is interested in building IP-based networks where each node needs an
address on the worldwide Internet. Three special ranges (blocks) of IP addresses
have been reserved for use in local networks. These "private ranges" or "private
addresses" are:
191
10.0.0.0 through 10.255.255.255
127.0.0.0
172.16.0.0 through 172.31.0.0
192.168.0.0 through 192.168.255.0
These addresses can always be used in local networks that do not directly connect to
the Internet. In fact they are not even supposed to connect to the Internet, and any
node that receives messages from outside its own network with one of these
addresses as the sender will discard such messages rightaway.
The reserved range of 127.0.0.0 is intended for use on a single node. Addresses in
this range are called loopback addresses. Only applications on the same node can
send packets to these addresses. This makes it possible, for example, to run a
Webserver from the address 127.0.0.1 so changes to a Website can be tested from
the Web designer's computer. Other people can never access that Webserver.
These reserved addresses are often used in conjunction with the Network Address
Translation (NAT) scheme, sometimes also called "IP Masquerading" or "Network
Masquerading". This means the private addresses are mapped to a single public IP
address so the nodes with these private addresses can still access the Internet. This
way no public IP address block needs to be allocated.
Network Address Translation (NAT)
The Network Address Translation (NAT) scheme is used to "hide" local networks from
the public Internet. Essentially, all communication from that local network appears to
come from a single node, the NAT gateway. The NAT gateway forwards requests
from other nodes in that network, and also pasess on responses from outside to the
right node on the internal network.

192
A network with a NAT gateway
As shown in the figure, three computers on a local network have private addresses
10.0.0.1, 10.0.0.2 and 10.0.0.3. They are connected with a hub which in turn
connects to a NAT gateway. If any of these computers contacts the server on the
right via the Internet, the server always sees the NAT gateway's IP address (here
171.67.2.3).
The NAT gateway
The NAT gateway is both connected to the local network and to the Internet. It
receives the IP packets that are intended for outside nodes. It registers from which
local node those packets came, and then replaces the source address with its own,
public IP address before forwarding the packets to the real destination.
Incoming packets are also received by the NAT gateway, which determines the real
intended destination, replaces the destination address (its own IP address) with the
real, local IP address and forwards the packets onto the local network.
On-the-fly NAT address replacement
This on-the-fly address replacement is possible because the NAT gateway examines
the IP packets for the TCP or UDP ports mentioned in those packets. In TCP a
connection is established between a port on the client and a port on the server. The
gateway registers both the local source IP address and the source port. It then
replaces the source port number with a new port number it chooses itself. Incoming

193
responses from the external server carry that port number, allowing the gateway to
determine to which local host. the packet is to be forwarded.
A problem with NAT is that some application-level protocols do not work well, as they
rely on the IP address provided by the real source. Since that is often a private and
thus unreachable address, the communication will fail.
IP address assignment
Before a computer or other device can be connected to an IP network, it needs to be

assigned an IP address. The most straightforward way is to statically assign the
address: simply enter the address (and netmask) into a configuration screen. That
address will then be used until it is again manually changed. This works well for
small networks or networks that are rarely changed.
Static address assignment
If an IP address is likely to change, or manually updating addressing is problematic,

a dynamic assignment is preferred. Here the computer that tries to connect to the
network is sent a message from some server telling which IP address and netmask
to use.
Dynamic address assignment: DHCP
Dynamic assignment is today most commonly done with the Dynamic Host
Configuration Protocol (DHCP). When trying to connect to a network, the computer
sends a request for an IP address. The DHCP server receives the request and assigns
or "leases" the address to that computer. A special "lease" message, containing the
IP address together with netmask and other network configuration information, is
then sent to that computer. The lease is valid for a certain period of time, after which
the computer will request a new one.
The address in a lease is taken from a certain block, called the pool in DHCP
terminology).The address that is sent in such a lease can be the same every time,
although this is not required.

194
TCP/IP
TCP/IP (Transmission Control Protocol/Internet Protocol) is the basic communication

language or protocol of the Internet. It can also be used as a communications
protocol in a private network (either an intranet or an extranet). When you are set
up with direct access to the Internet, your computer is provided with a copy of the
TCP/IP program just as every other computer that you may send messages to or get
information from also has a copy of TCP/IP.
TCP/IP is a two-layer program. The higher layer, Transmission Control Protocol,

manages the assembling of a message or file into smaller packets that are
transmitted over the Internet and received by a TCP layer that reassembles the
packets into the original message. The lower layer, Internet Protocol, handles the
address part of each packet so that it gets to the right destination. Each gateway
computer on the network checks this address to see where to forward the message.
Even though some packets from the same message are routed differently than
others, they'll be reassembled at the destination.
TCP/IP uses the client/server model of communication in which a computer user (a

client) requests and is provided a service (such as sending a Web page) by another
computer (a server) in the network. TCP/IP communication is primarily point-to-
point, meaning each communication is from one point (or host computer) in the
network to another point or host computer. TCP/IP and the higher-level applications
that use it are collectively said to be "stateless" because each client request is
considered a new request unrelated to any previous one (unlike ordinary phone
conversations that require a dedicated connection for the call duration). Being
stateless frees network paths so that everyone can use them continuously. (Note
that the TCP layer itself is not stateless as far as any one message is concerned. Its
connection remains in place until all packets in a message have been received.)
Many Internet users are familiar with the even higher layer application protocols that
use TCP/IP to get to the Internet. These include the World Wide Web's Hypertext
Transfer Protocol (HTTP), the File Transfer Protocol (FTP), Telnet (Telnet) which lets
you logon to remote computers, and the Simple Mail Transfer Protocol (SMTP). These
and other protocols are often packaged together with TCP/IP as a "suite."

195
Personal computer users with an analog phone modem connection to the Internet
usually get to the Internet through the Serial Line Internet Protocol (SLIP) or the
Point-to-Point Protocol (PPP). These protocols encapsulate the IP packets so that
they can be sent over the dial-up phone connection to an access provider's modem.
Protocols related to TCP/IP include the User Datagram Protocol (UDP), which is used
instead of TCP for special purposes. Other protocols are used by network host
computers for exchanging router information. These include the Internet Control
Message Protocol (ICMP), the Interior Gateway Protocol (IGP), the Exterior Gateway
Protocol (EGP), and the Border Gateway Protocol (BGP).
FIGURE 6. Network Address Translation (NAT).

196
FIGURE 7. Port Address Translation (PAT).

197
UDP: User datagram Protocol
UDP, described in RFC 768, provides an end-to-end datagram (connectionless)

service. Some applications, such as those that involve a simple query and response,
are better suited to the datagram service of UDP because there is no time lost to
virtual circuit establishment and termination. UDP's primary function is to add a port
number to the IP address to provide a socket for the application.
1111111111222222222233
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+
| Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-
FIGURE 9. UDP datagram format.
The fields of a UDP datagram (Figure 9) are:
Source Port: Identifies the UDP port being used by the sender of the datagram; use
of this field is optional in UDP and may be set to 0.
Destination Port: Identifies the port used by the datagram receiver.
Length: Indicates the total length of the UDP datagram.
Checksum: Provides bit error detection for the UDP datagram. The checksum field
covers the UDP datagram header and data, as well as a 96-bit pseudo header that

198
contains the IP header Source Address, Destination Address, and Protocol fields, as
well as the UDP datagram length.
UDP (User Datagram Protocol) is a communications protocol that offers a limited

amount of service when messages are exchanged between computers in a network
that uses the Internet Protocol (IP). UDP is an alternative to the Transmission
Control Protocol (TCP) and, together with IP, is sometimes referred to as UDP/IP.
Like the Transmission Control Protocol, UDP uses the Internet Protocol to actually get
a data unit (called a datagram) from one computer to another. Unlike TCP, however,
UDP does not provide the service of dividing a message into packets (datagrams)
and reassembling it at the other end. Specifically, UDP doesn't provide sequencing of
the packets that the data arrives in. This means that the application program that
uses UDP must be able to make sure that the entire message has arrived and is in
the right order. Network applications that want to save processing time because they
have very small data units to exchange (and therefore very little message
reassembling to do) may prefer UDP to TCP. The Trivial File Transfer Protocol (TFTP)
uses UDP instead of TCP.
UDP provides two services not provided by the IP layer. It provides port numbers to
help distinguish different user requests and, optionally, a checksum capability to
verify that the data arrived intact.

199
HTTP:
The Hypertext Transfer Protocol is the basis for exchange of information over the
World Wide Web (WWW). Various versions of HTTP are in use over the Internet, with
HTTP version 1.0 (RFC 1945) being the most current. WWW pages are written in the
Hypertext Markup Language (HTML), an ASCII-based, platform-independent
formatting language (RFC 1866).
HTTP (Hypertext Transfer Protocol) is the set of rules for transferring files (text,
graphic images, sound, video, and other multimedia files) on the World Wide Web.
As soon as a Web user opens their Web browser, the user is indirectly making use of
HTTP. HTTP is an application protocol that runs on top of the TCP/IP suite of
protocols (the foundation protocols for the Internet).
HTTP concepts include (as the Hypertext part of the name implies) the idea that files
can contain references to other files whose selection will elicit additional transfer
requests. Any Web server machine contains, in addition to the Web page files it can
serve, an HTTP daemon, a program that is designed to wait for HTTP requests and
handle them when they arrive. Your Web browser is an HTTP client, sending requests
to server machines. When the browser user enters file requests by either "opening" a
Web file (typing in a Uniform Resource Locator or URL) or clicking on a hypertext
link, the browser builds an HTTP request and sends it to the Internet Protocol
address (IP address) indicated by the URL. The HTTP daemon in the destination
server machine receives the request and sends back the requested file or files
associated with the request. (A Web page often consists of more than one file.)

200
Using and interpreting relative URLs
The abbreviation URL stands for Uniform Resource Locator. It is a simple way of
indicating the address of a certain resource and because of its easy format; it does
not a need a program to get parsed.
In a document with a given URL , it is possible to give the URL of another document
relative to the URL of the current document. This relative URL is usually much
shorter than the full URL.
Structure of an URL
An URL looks like this:
http://me:mypass@www.myhost.org:81/users/galactus/file.html
^ ^ ^ ^ ^ ^--- local URL part
| | | | |------ port number
| | | ---------------------- hostname of server, or IP address
| | ----------------------------- password (optional)
| -------------------------------- username (optional)
--------------------------------------- protocol name
In most cases, the username, password and port number are omitted. It is also
possible that the local URL part ends in a slash, in which case it is called a directory
URL.
If the local URL starts with a slash, it is called an absolute local URL, otherwise it is
called a relative (local) URL.
What are relative URLs?
Put simply, it's an URL which needs some processing before it is valid. It is a local URL,
from which certain information is left out. Often this means some directory names have
been left off, or the special sequence ../ is being used.
The "relative" comes from the fact that the URL is only valid relative to the URL of
the current resource.

201
Resolving relative URLs
As said, a relative URL needs the URL of the current resource to be interpreted
correctly. With some simple manipulations, the relative URL is transformed into an
absolute URL, which is then fetched as usual.
A relative URL is always a local URL. The first part is therefore always the same as
that of the current URL. The relative URL is then turned into an absolute local URL
with the following simple steps:
1.Omit the filename of the current absolute local URL, if it's not a directory URL.
2.For every ../ at the beginning of the relative URL, chop off one directory name
from the current directory URL.
3.Append the local URL to the current one.
A few simple examples
In these examples, we assume that the full URL of the current document is
http://www.foo.com/users/galactus/index.html
Relative URL: myessay.html
The full URL for this relative URL is

http://www.foo.com/users/galactus/myessay.html
Relative URL: pics/background.gif
The full URL for this relative URL is

http://www.foo.com/users/galactus/pics/background.gif
Relative URL: ../cgi-bin/myscript.pl.
The full URL for this relative URL is http://www.foo.com/users/cgi-bin/myscript.pl

202
Note that it is not necessarily true that the ../ bit in a relative URL refers to going
"up" one directory on the server. It may often be the case, since that's the most
simple and common way to do it, but the ../ applies to the URL, not the actual
directory tree on the server.
As you can see in the last example, it is quite possible that ../ ends you in a totally
different directory on the server.

203
FTP: The File Transfer Protocol allows a user to transfer files between local and
remote host computers
FTP Protocol Overview
FTP, the File Transfer Protocol, documented in RFC 959, is one of oldest Internet
protocols still in widespread use. FTP is implemented using the TCP Protocol.
As shown in the following diagram, FTP uses separate command and data
connections. The Protocol Interpreter (PI) implements the FTP protocol itself, while
the Data Transfer Process (DTP) actually performs data transfer. The FTP protocol
and the data transfer use entirely separate TCP sessions.
-------------
|/---------\|
|| User || --------
||Interface|<--->| User |
|\----^----/| --------
---------- | | |
|/------\| FTP Commands |/----V----\|
||Server|<---------------->| User ||
|| PI || FTP Replies || PI ||
|\--^---/| |\----^----/|
| | | | | |
-------- |/--V---\| Data |/----V----\| --------
| File |<--->|Server|<---------------->| User |<--->| File |
|System| || DTP || Connection || DTP || |System|
-------- |\------/| |\---------/| --------
---------- -------------
Server-FTP USER-FTP
NOTES: 1. The data connection may be used in either direction.

2. The data connection need not exist all of the time.

204
FTP servers listen on port 21. Data connections are initiated by the server
from its port 20, to a port on the client identified in a PORT command.
For a discussion of running FTP through firewalls, see RFC 1579.
File Transfer Protocol
File Transfer Protocol (FTP), a standard Internet protocol, is the simplest way to
exchange files between computers on the Internet. Like the Hypertext Transfer
Protocol (HTTP), which transfers displayable Web pages and related files, and the
Simple Mail Transfer Protocol (SMTP), which transfers e-mail, FTP is an application
protocol that uses the Internet's TCP/IP protocols. FTP is commonly used to transfer
Web page files from their creator to the computer that acts as their server for
everyone on the Internet. It's also commonly used to download programs and other
files to your computer from other servers.
As a user, you can use FTP with a simple command line interface (for example, from
the Windows MS-DOS Prompt window) or with a commercial program that offers a
graphical user interface. Your Web browser can also make FTP requests to download
programs you select from a Web page. Using FTP, you can also update (delete,
rename, move, and copy) files at a server. You need to logon to an FTP server.
However, publicly available files are easily accessed using anonymous FTP.
Basic FTP support is usually provided as part of a suite of programs that come with
TCP/IP. However, any FTP client program with a graphical user interface usually
must be downloaded from the company that makes it
When and How to Use File Transfer Protocol

205
"In the last analysis, our only freedom is the freedom to discipline
ourselves."
What Is FTP All About?
Very briefly, FTP (File Transfer Protocol) is used to transfer programs or other
information from one computer to another. This simple tool will let you do many
things: download software, upload your own web pages, transfer information
between your home and work machines, and more. You don't need to learn a lot of
confusing commands, either. As is so often true with computers, the right tool makes
the job much easier
Ping: A utility that allows a user at one system to determine the status of other
hosts and the latency in getting a message to that host. Uses ICMP Echo messages.
The hierarchical structure of domain names is best understood if the domain name is
read from right-to-left. Internet hosts names end with a top-level domain name.
World-wide generic top-level domains (TLDs) include:
.com: Commercial organizations (administered by VeriSign Global Registry Services

through the Shared Registry System)
.edu: Educational institutions; largely limited to 4-year colleges and universities from
about 1994 to 2001, but also includes some community colleges (administered by
EDUCAUSE)
.net: Network providers; laregely limited to hosts actually part of an operational

network from about 1994 to 2001 but now open to anyone, including the author of
this paper! (administered by VeriSign Global Registry Services through the Shared
Registry System)
.org: Non-profit organizations (administered by VeriSign; after January 2003, will be

administered by the Public Interest Registry (PIR), an organization formed by ISOC
with operational control subcontracted to Afilias, the operator of the .info domain)
.int: Organizations established by international treaty

206
.gov: U.S. Federal government agencies (managed by the U.S. General Services
Administration, including the fed.us domain)
.mil: U.S. military (managed by the U.S. Department of Defense Network

Information Center)

207
TOR: The Onion Router
TOR or Tor is an abbreviation for The Onion Router. As the Tor homepage puts it
"Tor is a network of virtual tunnels that allows people and groups to improve their
privacy and security on the Internet." Tor uses so-called onion routing to defend
against privacy attacks. Onion routing relies on multiple layers of security that are
removed (like onion skin) one by one as a message is routed through the Tor
network.
To explain what onion routing is, I will elaborate on Tor as this is the leading
software utilising onion routing. I will first give a short introduction what routing and
routing protocols are, there after which technologies are used to achieve enhanced
communication anonymity and subsequently, how Tor makes use of these techniques
and in which way it differs from (traditional) onion routing.
Introduction to routing
Routing can be defined as the complete system of selecting appropriate paths in a

computer network along which data should be sent or forwarded from one location to
another. This path is built out of a string of nodes, which all receive a data packet
and subsequently send it to the next node in the path. This path should result in the
most efficient and effective connection between location A and location B.
The rules: routing protocols
Routing is most effective if one or more routing protocols are in use. A routing
protocol is in essence a set of rules used by nodes to determine the most
appropriate paths into which they should forward packets towards their intended
destinations. A routing protocol specifies amongst others how intermediary nodes
report changes in the network and share this information with the other nodes in the
network.
Without a routing protocol, the network cannot dynamically adjust to changing

conditions, resulting in the fact that all routing decisions are predetermined and thus
static.

208
Routing in practice: an example
I will use a simplified example to clarify these definitions however the principle is the
same irrespective of the scale of the network. If Alice would like to connect to Bob,
she sends a request to her ISP to find out which route should be used to make a
connection and her provider will respond with the routing information.
After Alice's computer received the route to be used the request will be split into
smaller data packets and sent to the first node which in turn sends the packet to the
consecutive nodes to eventually reach Bob.
A risk: Traffic analysis
Even though routing is being used on an everyday basis and its use is widespread, it
does have a disadvantage. Public networks like the Internet are very vulnerable to
traffic analysis because, e.g. packet headers identify the IP addresses of the
recipient(s) and the packet routes can rather easily be tracked.
Of course transmissions can be encrypted, so that an attacker cannot learn the

content of these transmissions. This however still reveals the fact that two parties
are communicating. If for example a government official is sending encrypted data to
a website of the opposition, and later that site publishes a document that was
supposed to be secret, it is pretty clear what happened.
To explain how enhanced communication anonymity can be reached I will give an

overview of two extensively used approaches. First of all digital mixing and
afterwards anonymizing proxies.
Digital mixing
Figure 1: Encryption in three layers

209
In the early eighties of the last century, David Chaum invented the principle of
digital mixes (sometimes called mix networks) to achieve a higher level of
anonymity with personal communication. Digital mixing uses a similar system as
routing but it adds several layers in the connection between the sender and receiver
of the communication. Figure 1 illustrates how these layers function in practice. The
layers are created using public key cryptography.
Mixing the message
If Alice wants to send a message to Bob, without a third person being able to find
out who the sender or recipient is, she would encrypt her message three times with
the aid of public key cryptography. She would then send her message to a proxy
server who would remove the first layer of encryption and send it to a second proxy
server through the use of permutation. This second server would then decrypt and
also permute the message and the third server would decrypt and send the message
to the intended recipient. This is illustrated in the figure below.
Figure 2: Digital mixing - a three-layered encrypted message being

processed
Using digital mixing is comparable to sending a letter encased in four envelopes pre-
addressed and pre-stamped with a small message reading, "please remove this
envelope and repost". (With the difference of course that the encryption of the
message is not easily removed as an envelope.) If the three successive recipients
would indeed post the letter, the letter would reach the intended recipient without
there being a paper trail between the initial sender and the intended recipient.

210
Security of digital mixing systems
This system is effective because as long as the three successive recipients, the re-
senders, send enough messages it is impossible for a third person e.g. an ISP, and
subsequently government (policing) agencies, to find out what message was
originally sent by whom and to whom.
Digital mixing also has some downsides. First of all, it only works if the re-senders
send enough messages (at any given moment and during a set amount of time e.g.
a day). However, because (most) nodes, the resending servers, do not send enough
messages at the same time, digital mixing would be vulnerable to statistical analysis
such as data mining by governments or government policing agencies.
By making use of e.g. a threshold batching strategy the proxy servers are able to
solve this lack of messages at the same moment. However, this results in the fact
that the period between the sending and the eventual receiving of the message by
the intended recipient can be several hours depending on the amount of messages
deemed critical. Which means a threshold batching strategy makes digital mixing a
(rather) slow technique.
And because the use of public key cryptography in itself is not very fast, it would not
take several hours for a series of proxy servers to decrypt and permute a message
but it would be significantly longer than a normal transfer lasting milliseconds.
This all results in the conclusion that digital mixing is only effective in case of static data
packages such as e-mails, because if digital mixing were to be used for web browsing or
data transfer a high latency would be the result. This in turn means that digital mixing is
not a suitable solution for one who wants anonymity while web browsing or conducting
data transfers with the aid of e.g. FTP servers.

211
Anonymizing proxies
An anonymizing proxy server is a server whose only function is to be a node. This

means it only reroutes requests from one location to another. If Alice wants to make
a connection to Bob without him knowing that it is Alice connecting to him, she
would fill in Bobs IP address at a proxy server. The proxy server would then make a
connection to Bob and relay all the information Bob sends to it to Alice.
Figure 3: An anonymizing proxy connecting several nodes
The system of proxy servers has many positive aspects. Firstly it is useable for both
static-, e.g. e-mail, and dynamic data packets, such as web browsing. Secondly,
proxy servers do not require expensive techniques like public key encryption to
function, and thirdly it is an easy system. A user only needs to connect to a proxy
server via his or her web browser to use it, as is illustrated by figure 3 above.
However, anonymizing proxies have one fatal flaw, which makes them less than reliable
for anyone who wants anonymous communication. If an unreliable third party controls
the proxy server, e.g. a group of criminals who use the proxy server for phishing, the user
is no longer guaranteed of a secure, and anonymous, communication.
Onion routing with Tor
Instead of using one specific technique of the aforementioned techniques, Tor

combines specific aspects of both digital mixing and anonymizingg proxies. I will first
explain how using Tor can enhance anonymity to elaborate afterwards on the
differences between Tor and classic onion routing (Wikipedia).

212
Figure 4: How Tor works (1) - getting a directory listing
Connecting to the Tor network
If Alice wants to make a connection to Bob through the Tor network, she would first
make an unencrypted connection to a centralised directory server containing the
addresses of Tor nodes as illustrated. After receiving the address list from the
directory server the Tor client software will connect to a random node (the entry
node), through an encrypted connection. The entry node would make an encrypted
connection to a random second node which would in turn do the same to connect to
a random third Tor node.
That third node, the exit node, would then connect to Bob as visualised below. Every
Tor node is chosen at random (However, the same node cannot be used twice in one
connection and depending on data congestion some nodes will not be used.) from
the address list received from the centralised directory server, both by the client and
and by the nodes, to enhance the level of anonymity as much as possible.

213
Figure 5: How Tor works (2) - Alice connecting to Bob

214
Changing routes
If the same connection, the same array of nodes, were to be used for a longer period
of time a Tor connection would be vulnerable to statistical analysis, which is why the
client software changes the entry node every ten minutes, as illustrated.
Figure 6: How Tor works (3) - the route to Bob changes
Increasing anonymity by becoming a node
To increase anonymity Alice could also opt to run a node herself. I mentioned earlier
that the identity of all Tor nodes is public, which could lead to the conclusion that
running a node would not increase the level of anonymity for Alice. This notion would
however not be correct.
I will try to explain why running a Tor node actually increases anonymity. If Alice
uses the Tor network to connect to Bob, she does this by connecting to a Tor node,
however if she functions as node for Jane she would also connect to a Tor node. This
would result in a situation in which a malevolent third party would not be able to
know which connection is initiated as a user and which as node.

215
Figure 7: How Tor works (4) - Alice as a Tor node
Which means this makes data mining significantly more difficult, and in a
situation where Alice functions as a node for dozens of users, it makes data mining
virtually impossible. As Roger Dingledine said it poignantly, "Anonymity loves
company [...] it is not possible to be anonymous alone". This is also one of the
reasons why the United States Department of Defence funded and still funds,
amongst others through organisations such as DARPA and CHACS, the research,
development and refinement of Tor.
SNMP Tutorial Part 1: An Introduction to SNMP
Since its creation in 1988 as a short-term solution to manage elements in the

growing Internet and other attached networks, SNMP has achieved widespread
acceptance. SNMP was derived from its predecessor SGMP (Simple Gateway
Management Protocol) and was intended to be replaced by a solution based on the
CMIS/CMIP (Common Management Information Service/Protocol) architecture. This
long-term solution, however, never received the widespread acceptance of SNMP.

216
SNMP is based on the manager/agent model consisting of an SNMP manager, an
SNMP agent, a database of management information, managed SNMP devices and
the network protocol. The SNMP manager provides the interface between the human
network manager and the management system. The SNMP agent provides the
interface between the manager and the physical device(s) being managed (see the
SNMP is based on the manager/agent model of a network

anagement architecture
illustration above).
The SNMP manager and agent use an SNMP Management Information Base (MIB)
and a relatively small set of commands to exchange information. The SNMP MIB is
organized in a tree structure with individual variables, such as point status or
description, being represented as leaves on the branches. A long numeric tag or
object identifier (OID) is used to distinguish each variable uniquely in the MIB and in
SNMP messages.
SNMP uses five basic messages (GET, GET-NEXT, GET-RESPONSE, SET, and TRAP) to
communicate between the SNMP manager and the SNMP agent. The GET and GET-
NEXT messages allow the manager to request information for a specific variable. The
agent, upon receiving a GET or GET-NEXT message, will issue a GET-RESPONSE
message to the SNMP manager with either the information requested or an error

217
indication as to why the request cannot be processed. A SET message allows the
SNMP manager to request a change be made to the value of a specific variable in the
case of an alarm remote that will operate a relay. The SNMP agent will then respond
with a GET-RESPONSE message indicating the change has been made or an error
indication as to why the change cannot be made. The SNMP TRAP message allows
the agent to spontaneously inform the SNMP manager of an "important" event.
As you can see, most of the messages (GET, GET-NEXT, and SET) are only issued by
the SNMP manager. Because the TRAP message is the only message capable of being
initiated by an SNMP agent, it is the message used by DPS Remote Telemetry Units
(RTUs) to report alarms. This notifies the SNMP manager as soon as an alarm
condition occurs, instead of waiting for the SNMP manager to ask.
The small number of commands used is only one of the reasons SNMP is "simple."
The other simplifying factor is the SNMP protocol's reliance on an unsupervised or
connectionless communication link. This simplicity has led directly to the widespread
use of SNMP, specifically in the Internet Network Management Framework. Within
this framework, it is considered "robust" because of the independence of the SNMP
managers from the agents, e.g. if an SNMP agent fails, the SNMP manager will
continue to function, or vice versa. The unsupervised communication link does
however create some interesting issues for network alarm monitoring we will discuss
more thoroughly in a later issue of our SNMP tutorial.

218
Telnet
Telnet programs are a type of terminal emulation program, just like modem-based
communications programs. The difference is that they allow you to access other
computers through the Internet, rather than by dialing the other computers directly.
Telnet programs "talk" to other Internet-connected computers using what's called

the "telnet protocol" for communication. This protocol specifies how telnet programs
should send data back and forth, allowing for interactive text sessions. The folllowing
is an example of an interactive session, with the remote computer displaying text,
then waiting for the user to type some text:
Connecting to xyzzy.com....
Please enter your login: jsmith
Password? *****
Welcome, jsmith. You have 3 new messages.
Read them now (y/n)? y
If you've accessed BBSs by modem before, using a communications program, then
you'll find telnet is similar. But it allows you to access Internet-connected BBSs and
other systems world-wide.
In addition to being a type of program and a protocol, telnet can also be used as a
verb. To telnet to a system means to connect to a system with a telnet program

219

Load Runner Performance Testing

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Load Runner Performance Testing

Uploaded by

Copyright:

Available Formats

HP Performance Center (Load Runner)

Performance testing by using Load Runner

HP Load Runner by Satyam QEdge Performance SO, Hyderabad

1.0 Performance Testing

1.1 Why Performance testing?

HP Load Runner by Satyam QEdge Performance SO, Hyderabad

1.3 Performance Testing using “LESS” Approach

• Evaluate the adequacy of a load balancer.

What risks does it address?

HP Load Runner by Satyam QEdge Performance SO, Hyderabad

1.3.2 Endurance Testing

A performance test focused on determining or validating performance characteristics

• Slow memory leaks

1.3.3 Stress testing

Performance tests focused on determining or validating performance characteristics

HP Load Runner by Satyam QEdge Performance SO, Hyderabad

What are the benefits?

• Determining if data can be corrupted by over stressing the system

1.3.4 Spike Testing

A performance test focused on determining or validating performance characteristics

1.4 Scalability testing:

1.5 Volume testing

HP Load Runner by Satyam QEdge Performance SO, Hyderabad

1.6 Capacity Testing

• Conduct various tests to compare capacity planning models and/or

HP Load Runner by Satyam QEdge Performance SO, Hyderabad

2.0 Introduction to Load Runner

Using a minimum of hardware resources, these Virtual Users provide consistent,

Load Runner emulates an environment in which thousands of users work with a

2.1 The Load Runner advantages over Manual performance testing:

HP Load Runner by Satyam QEdge Performance SO, Hyderabad

HP Load Runner by Satyam QEdge Performance SO, Hyderabad

HP Load Runner by Satyam QEdge Performance SO, Hyderabad

2.5 Load Runner Vuser Types

• Client/Server: For MSSQLServer, ODBC, Oracle (2-tier), DB2 CLI, Sybase

HP Load Runner by Satyam QEdge Performance SO, Hyderabad

HP Load Runner by Satyam QEdge Performance SO, Hyderabad

HP Load Runner by Satyam QEdge Performance SO, Hyderabad

3.0 The LoadRunner Testing Process /Performance Testing Life Cycle

Planning the Test

Creating Vuser Script

Creating the Scenario

Running the Scenario

Monitoring the Scenario

Analyzing Test Results

Step I: Planning the Test

Analyzing the application

Defining the Load test objectives

HP Load Runner by Satyam QEdge Performance SO, Hyderabad

Planning LoadRunner Implementation

Examining Load Testing Objectives

Step II: Creating the Vuser Scripts

Step III: Creating the Scenario

HP Load Runner by Satyam QEdge Performance SO, Hyderabad

Step IV: Running the Scenario

Step V: Monitoring a Scenario

Step VI: Analyzing Test Results

HP Load Runner by Satyam QEdge Performance SO, Hyderabad

3.1 Scope of Performance Measurements:

Client Middle Ware Server

Measuring the network and server response time:

GUI Response time