LR81 Student 01D

Fundamentals of LoadRunner
8.1
Student Workbook
EDUCATION DEVELOPMENT
LR81-STUDENT-01D
All rights reserved. All text and figures included in this publication are the exclusive property of Mercury
Interactive Corporation or its licensors, and may not be copied, reproduced, or used in any way without the express
permission in writing of Mercury Interactive. Information in this document is subject to change without notice and
does not represent a commitment on the part of Mercury Interactive.
This document may also contain registered trademarks, service marks and/or trade names that are owned by their
respective companies or organizations. Mercury Interactive Corporation disclaims any responsibility for specifying
which marks are owned by which companies or organizations.
If you have any comments or suggestions regarding this document, please send them via
http://www.merc-training.com/feedback
© Copyright 1994 - 2005 by

Mercury Interactive Corporation
Table of Contents
Introduction
Course Objectives ............................................................................................................ 1-2
Why Load Test your Application?................................................................................... 1-3
Types of Performance Testing ......................................................................................... 1-4
Examples of Performance Test Objectives ...................................................................... 1-5
Load Testing in the Product Life Cycle........................................................................... 1-6
Manual Testing is Problematic ........................................................................................ 1-7
The LoadRunner Solution................................................................................................ 1-8
The LoadRunner Methodology........................................................................................ 1-9
LoadRunner’s Load Testing Components ..................................................................... 1-10
The LoadRunner Launch Screen ................................................................................... 1-11
The LoadRunner Scripting Component ......................................................................... 1-12
What is a Vuser? ............................................................................................................ 1-13
Supported Protocols ....................................................................................................... 1-14
What is a Scenario?........................................................................................................ 1-15
What is the Controller? .................................................................................................. 1-16
LoadRunner Performance Monitoring........................................................................... 1-17
Why Use Performance Monitors?.................................................................................. 1-18
Examples of LoadRunner Performance Monitors ......................................................... 1-19
Putting it all Together .................................................................................................... 1-20
The Load Testing Process.............................................................................................. 1-22
LoadRunner Expert Workflow - The Big Picture.......................................................... 1-23
LoadRunner Components in the Workflow................................................................... 1-24
Training Application for Web Protocol ......................................................................... 1-25
Contents of this Course.................................................................................................. 1-26
LoadRunner Resources .................................................................................................. 1-27
Summary........................................................................................................................ 1-28
Exercise: Product Overview .......................................................................................... 1-29
Planning an Effective Load Test

LoadRunner Expert Workflow - Establish Goals ............................................................ 2-2
How to Define Goals ....................................................................................................... 2-3
LoadRunner Expert Workflow - System Usage .............................................................. 2-4
Gather System Usage Information................................................................................... 2-5
What is a Business Process? ............................................................................................ 2-6
Examples of Business Processes...................................................................................... 2-7
Anatomy of a Business Processes.................................................................................... 2-8
Business Processes to Record:
1-1
Mission-Critical Transactions.......................................................................................... 2-9
Heavy Throughput Transactions.................................................................................... 2-10
Business Processes to Record
Dynamic Content ........................................................................................................... 2-11
Business Process Profile ................................................................................................ 2-12
Classroom Activity ........................................................................................................ 2-13
Measuring Steps............................................................................................................. 2-14
Measure Steps by Defining Transactions ...................................................................... 2-15
Preferred and Unacceptable Response Times................................................................ 2-16
Documenting User Steps and Input Data....................................................................... 2-17
Determine Valid Test Data to Use ................................................................................. 2-18
Valid Test Data Sources ................................................................................................ 2-19
What is Think Time? ..................................................................................................... 2-20
Navigation Time Reflects User Pauses.......................................................................... 2-21
What is a Concurrency? ................................................................................................. 2-22
Application Concurrency ............................................................................................... 2-23
Business Process Concurrency ...................................................................................... 2-24
Transactional Concurrency ............................................................................................ 2-25
User Profile .................................................................................................................... 2-26
Peak Load ...................................................................................................................... 2-27
Where are Your Customers Located? ............................................................................ 2-28
Transcontinental Remote Customers ............................................................................. 2-29
Quantifying Load Testing Goals.................................................................................... 2-30
LoadRunner Expert Workflow -
Analyze the System ....................................................................................................... 2-31
Analyze the System Under Test..................................................................................... 2-32
Understanding the System Components ........................................................................ 2-33
Business Process Mapping to Infrastructure Components ............................................ 2-34
Monitoring Application Components ............................................................................ 2-35
Planning System Monitoring ......................................................................................... 2-36
About the Test Environment.......................................................................................... 2-37
Benchmarking Run ........................................................................................................ 2-38
Summary........................................................................................................................ 2-39
Exercise: Planning an Effective Load Test.................................................................... 2-40
Installation
LoadRunner Expert Workflow - Installation ................................................................... 3-2
Where Do I Start? ............................................................................................................ 3-3
Where to Install Each Component ................................................................................... 3-4
Installing VuGen.............................................................................................................. 3-5
Installing the Controller ................................................................................................... 3-6
1-2
Installing Load Generators............................................................................................... 3-7
Install Load Generators to Reflect Customer Base.......................................................... 3-8
WAN Emulation .............................................................................................................. 3-9
Why Emulate Remote Users Performance?................................................................... 3-10
WAN Emulation - procedure ......................................................................................... 3-11
Installing Analysis ......................................................................................................... 3-12
Putting it all Together .................................................................................................... 3-13
Minimum Hardware Recommendation ......................................................................... 3-14
Need for Remote Infrastructure ..................................................................................... 3-15
Verifying Connectivity to a Load Generator ................................................................. 3-16
Troubleshooting Generator Connectivity Issues............................................................ 3-17
Summary........................................................................................................................ 3-18
Exercise: Installation...................................................................................................... 3-19
Introduction to Scenarios
LoadRunner Expert Workflow - Understanding Scenarios ............................................. 4-2
What is a Scenario ........................................................................................................... 4-3
The LoadRunner Controller............................................................................................. 4-4
Scenario Outline - Examples ........................................................................................... 4-5
Creating a New Scenario ................................................................................................. 4-6
Select Vuser Scripts ......................................................................................................... 4-7
Vuser Groups ................................................................................................................... 4-8
Adding a Vuser Group ..................................................................................................... 4-9
Modifying the Vuser Group Settings............................................................................. 4-10
Manual vs. Goal-Oriented Scenarios ............................................................................. 4-11
Which Scenario Type to Choose? Example .................................................................. 4-12
Selecting Load Generators for your Scenario................................................................ 4-13
Adding a Load Generator .............................................................................................. 4-14
Defining a New Load Generator.................................................................................... 4-15
Connecting to a Load Generator .................................................................................... 4-16
Configuring Load Generator Settings............................................................................ 4-17
Assigning User Profiles to Load Generators ................................................................. 4-18
Assigning User Profiles to Load Generators - Example................................................ 4-19
Assigning Number of Vusers......................................................................................... 4-20
Summary........................................................................................................................ 4-21
Exercise: Introduction to Scenarios ............................................................................... 4-22
Using Run-time Settings

LoadRunner Expert Workflow ........................................................................................ 5-2
About Run-time Setting ................................................................................................... 5-3
Vuser Run-time Settings .................................................................................................. 5-4
1-3
Run-time Settings Vary with Protocol............................................................................. 5-5
Accessing Run-time Settings ........................................................................................... 5-6
Run Logic ........................................................................................................................ 5-7
Configuring Run Logic - Example .................................................................................. 5-8
Pacing............................................................................................................................... 5-9
Log Settings ................................................................................................................... 5-10
Log Settings - Best Practices ......................................................................................... 5-11
What is Think Time? ..................................................................................................... 5-12
Enabling or Ignoring Think Time .................................................................................. 5-13
Configuring Think Time - Example .............................................................................. 5-14
Additional Attributes ..................................................................................................... 5-15
Miscellaneous Settings .................................................................................................. 5-16
Additional Settings for Web Vusers .............................................................................. 5-17
Additional Settings for Web Vusers - Examples ........................................................... 5-18
Scenario Run-time Settings - Defined ........................................................................... 5-19
Scenario Run-time Settings ........................................................................................... 5-20
Summary........................................................................................................................ 5-21
Exercise: Introduction to Scenarios ............................................................................... 5-22
Scenario Execution
About Running Scenarios ................................................................................................ 6-3
What is a Rendezvous Point?........................................................................................... 6-4
Rendezvous ...................................................................................................................... 6-5
Before You Run a Scenario ............................................................................................. 6-6
Executing Scenarios as a Team is Recommended........................................................... 6-7
Scenario Execution Process: Debug Run......................................................................... 6-8
What is a Top Time Transaction?.................................................................................... 6-9
Scenario Execution Process: Isolate Top Time Transactions ........................................ 6-10
Scenario Execution Process: Full Load ......................................................................... 6-11
Scenario Execution Process: Scalability Test ................................................................ 6-12
Best Practices ................................................................................................................. 6-13
Vuser Status - Under Controller Run Tab ..................................................................... 6-14
Initializing Vuser Groups............................................................................................... 6-15
Understanding Vuser Status........................................................................................... 6-16
Vuser Window and Vuser Log ...................................................................................... 6-18
Scenario Status - Controller Run Tab ............................................................................ 6-19
Scenario Errors .............................................................................................................. 6-20
Viewing Scenario Errors - Procedure ............................................................................ 6-21
Common Run Time Errors ............................................................................................ 6-22
Summary........................................................................................................................ 6-23
Exercise: Scenario Execution ........................................................................................ 6-24
1-4
Scheduling Scenarios
About Scheduling Scenarios ............................................................................................ 7-3
Configure Schedule Settings of the Scenario .................................................................. 7-4
Configure Scenario Start Time ........................................................................................ 7-5
Schedule by Scenario....................................................................................................... 7-6
Schedule by Group........................................................................................................... 7-7
Ramp Up .......................................................................................................................... 7-8
Ramp Down ..................................................................................................................... 7-9
Scenario Duration .......................................................................................................... 7-10
Scenario Duration - Best Practices ................................................................................ 7-11
Initialization ................................................................................................................... 7-12
What Happens When the Stop Button is Pressed? ........................................................ 7-13
Summary........................................................................................................................ 7-14
Exercise: Scheduling Scenarios ..................................................................................... 7-15
Performance Monitors
Transactions Are Not the Whole Story............................................................................ 8-3
The Value of Performance Monitors ............................................................................... 8-4
Using Performance Monitors........................................................................................... 8-5
Examples of LoadRunner Performance Monitors ........................................................... 8-6
Performance Monitors ..................................................................................................... 8-7
Selecting Online Monitors - Procedure ........................................................................... 8-8
License Information ......................................................................................................... 8-9
Set Monitoring Options ................................................................................................. 8-10
Set Monitoring Options - Procedure .............................................................................. 8-11
Configure Monitors........................................................................................................ 8-12
Configure Monitors Procedure ...................................................................................... 8-13
Monitor Measurements .................................................................................................. 8-14
Best Practices for Choosing Monitor Measurements .................................................... 8-15
Summary........................................................................................................................ 8-16
Exercise: Performance Monitors ................................................................................... 8-17
Results Analysis
Where did the Failure Occur? .......................................................................................... 9-2
Root Cause Analysis ........................................................................................................ 9-3
Did You Meet Your Goals............................................................................................... 9-4
Results Analysis - Setting the Stage ................................................................................ 9-5
Average Transaction Response Time .............................................................................. 9-6
1-5
Average Transaction Response Time Under Load .......................................................... 9-7
Transaction Response Time Percentile............................................................................ 9-8
Transaction Response Time Distribution ........................................................................ 9-9
Working with the Data................................................................................................... 9-10
Opening a New Graph ................................................................................................... 9-11
Drilling Down ................................................................................................................ 9-12
Setting Filters ................................................................................................................. 9-13
Analysis Session File Extensions .................................................................................. 9-14
Isolating the Network..................................................................................................... 9-15
Isolating the Network - Graph Analysis ........................................................................ 9-16
Isolating Network Issues................................................................................................ 9-17
Isolating Server Issues ................................................................................................... 9-18
Isolating Server Issues ................................................................................................... 9-19
Interpreting Graphs ........................................................................................................ 9-20
Time to First Buffer Breakdown.................................................................................... 9-21
Page Download Time Breakdown ................................................................................. 9-22
Use Auto Correlation Feature to Pinpoint Bottlenecks ................................................. 9-23
Auto Correlate - Time Range......................................................................................... 9-24
Auto Correlate - Correlation Options ............................................................................ 9-26
Displaying Analysis Reports ......................................................................................... 9-28
Displaying Analysis Reports - Procedure ...................................................................... 9-29
Summary........................................................................................................................ 9-30
Exercise: Results Analysis............................................................................................. 9-31
Project (Optional)
Building Effective Scenarios .......................................................................................... A-2
Introduction to Internet Protocols

OSI Model (Open Systems Interconnection)...................................................................B-2
Introduction to Internet Protocols ....................................................................................B-3
Typical Web Server Port Assignments ............................................................................B-4
HTTP/S ............................................................................................................................B-5
What does HTTP look like?.............................................................................................B-6
What is a Header? ............................................................................................................B-7
HTTP Status Codes..........................................................................................................B-8
...And What’s in the Body?..............................................................................................B-9
Browser Functions .........................................................................................................B-10
HTML ............................................................................................................................B-11
Summary........................................................................................................................B-12
Installation Guidelines When a Firewall is Present

LoadRunner Controller Inside a Firewall ........................................................................C-2
Working with Firewalls ...................................................................................................C-3
1-6
LoadRunner Controller Outside a Firewall .....................................................................C-4
LoadRunner Controller Outside a Firewall - cont. ..........................................................C-5
LoadRunner Solution .......................................................................................................C-6
LoadRunner Solution - Step 1 .........................................................................................C-7
Configure the Controller ................................................................................................C-10
Hardware and Software Recommendations...................................................................C-11
IP Spoofing
About IP Spoofing .......................................................................................................... D-2
........................................................................................................................................ D-3
The Routing of Web Client Requests is
IP-related......................................................................................................................... D-4
How are IP Addresses Used by Routing Tables? ........................................................... D-5
Routing Tables Use Destination Addresses to Find a Packet’s Next Step ..................... D-6
Web Servers Use the Client’s IP Address to Return Results.......................................... D-7
How are IP Addresses Used by Load Balancing Systems? ............................................ D-8
Load Balancing Systems Rely on the IP Address of the Client...................................... D-9
Virtual Users Generally Reside at a Single IP Address................................................ D-10
Unbalanced Load Modeling Causes Uncertain Test Results........................................ D-11
...................................................................................................................................... D-12
IP Spoofing Issues ........................................................................................................ D-13
IP Spoofing Issues ........................................................................................................ D-14
The IP Wizard ............................................................................................................... D-15
The IP Wizard ............................................................................................................... D-16
Add Intranet/LAN Addresses ....................................................................................... D-17
Add Internet Addresses................................................................................................. D-18
The IP Wizard ............................................................................................................... D-19
Implementing the IP Spoofer ........................................................................................ D-20
Implementing the IP Spoofer ........................................................................................ D-21
IP Spoofing Results in Well-Distributed Load Modeling ............................................ D-22
Summary....................................................................................................................... D-23
Class Evaluation Form..................................................................................................... 1-1
1-7
1-8
Introduction
Introduction
Objectives
After completing this chapter, you will be able to:
• Explain the need for load testing.
• Describe various types of performance test objectives.
• Identify the steps of the LoadRunner methodology.
• Define the term “scenario” in the context of LoadRunner.
1-1
Introduction
Course Objectives
Welcome to the FUNDAMENTALS OF LOADRUNNER course. These materials are intended
for anyone who creates scenarios or runs load tests with LoadRunner. Both introductory
concepts like creating and configuring scenarios as well as advanced topics like results
analysis are covered.
After completing this course, you will be able to:
• Identify what information needs to be gathered for load testing.
• Identify the components of LoadRunner.
• Apply the workflow recommended for creating a basic LoadRunner scenario.
• Assign scripts, run-time settings, performance monitors, load generators and Vusers
to a LoadRunner scenario based on your load testing goals.
• Load test your application by running a scenario.
1-2 Course Objectives

Introduction
Why Load Test your Application?

Load testing your application provides many potential benefits.
• Preventing costly failures of mission-critical applications.
• Assuring performance and functionality under real-world conditions.
• Locating potential problems before your customers do.
• Reducing development time.
• Reducing infrastructure costs.
Scalability, reliability, and responsiveness are crucial issues for any application.
Traffic volumes can change dramatically in a matter of seconds. Long waits,
sluggish performance, or errors can send customers to the competition. At the same
time, multi-tiered architectures grow more and more complex.
Bottlenecks and crashes can occur anywhere. Before your system goes live, what can
you do to optimize performance and minimize future headaches?
Slowdowns and bottlenecks can be identified in advance by testing the site with
simulated user traffic. This process is known as load testing. Organizations
performing a load test for the first time are usually surprised to learn that their
infrastructure can handle only about 15% of expected traffic before performance
degrades dramatically.
After the load test, adjustments ranging from minor tweaks to major
reconfigurations can vastly improve system performance. The load test can then be
repeated to find further problems or to retest the system over time. Because it improves
customer satisfaction and avoids unnecessary upgrades, the load testing cycle is a
crucial step in the development of any Web application.
Why Load Test your Application? 1-3

Introduction
Types of Performance Testing
Figure 1-1 Types of performance testing
After site developers have performed “sanity testing” to check basic functionality, there
are several methodologies for testing application performance under load.
A component testing objective could be to tune the database server to support the
maximum load possible using the current hardware.
The most fundamental testing form is known simply as “load testing”. Load testing is
defined as a short-term test of performance under real-world conditions. By
understanding average response time, site architects can confirm that the goals of the
design have been achieved.
For stress testing, the first objective could be to determine stress points. An
example would be to determine the maximum number of transactions, per second, that
the application can support. The second objective could be to find when the system
approaches maximum capacity. An example would be to determine at what capacity (80,
90, 100 or 100++) the non-critical services (e.g. display of flights availability graphs)
will be shut down, in the order of least to most important.
1-4 Types of Performance Testing

Introduction
Examples of Performance Test Objectives
Performance Test Objective Explanation
Application response time How long does it take to complete a task?

Configuration sizing Which configuration provides the best
performance level?
Acceptance Is the system stable enough to go into production?
Regression Does a new version of the software adversely
affect response time?
Reliability How stable is the system under a heavy work
load?
Capacity planning At what point does performance degradation
occur?
Bottleneck identification What is the cause of degradation in performance?
Product evaluation What is the best server for 100 users?
Table 1-1.
Examples of Performance Test Objectives 1-5

Introduction
Load Testing in the Product Life Cycle
Figure 1-2 Load testing occurs throughout the product life cycle
The longer you wait to begin performance testing, the more costly the problem may
become. From a strictly financial point of view, performance testing should begin as
early as possible during the development cycle.
Load testing is necessary throughout the product life cycle.
1-6 Load Testing in the Product Life Cycle

Introduction
Manual Testing is Problematic
Figure 1-3 Problems of manual load testing
The limitations of manual testing make it difficult to achieve meaningful load test
results.
• How can site developers generate enough load to enable testing?
• How can I obtain sufficient testing personnel and client machines?
• How can I synchronize users?
• How do I measure the results?
• How can I repeat the test after identifying and fixing problems?
Manual Testing is Problematic 1-7

Introduction
The LoadRunner Solution
Figure 1-4 LoadRunner’s load testing solution
LoadRunner provides you with tools that address the issues associated with manual
testing.
LoadRunner eliminates the need for hundreds of testers and massive resources. Instead,
“virtual users” execute test steps which have been recorded so they can be repeated.
These test steps are saved as scripts and are organized as “scenarios”, eliminating the
need to coordinate testing manually.
1-8 The LoadRunner Solution

Introduction
The LoadRunner Methodology
Figure 1-5 The LoadRunner methodology
LoadRunner is a complete solution for conducting automated load testing before,

during, and after application deployment.
• LoadRunner Methodology
– Scale the application to a predetermined capacity
– Identify business processes or system components having trouble
– Diagnose a problem to pinpoint the root cause
The LoadRunner Methodology 1-9

Introduction
LoadRunner’s Load Testing Components
Figure 1-6 Load testing components
1-10 LoadRunner’s Load Testing Components

Introduction
The LoadRunner Launch Screen
Figure 1-7 The LoadRunner launch screen
The LoadRunner Launch Screen provides access to all the LoadRunner components.
The LoadRunner Launch Screen 1-11

Introduction
The LoadRunner Scripting Component
Figure 1-8 The LoadRunner scripting component
Accurate scripts form the foundation of an effective load test. Once planning is
completed the next step is to move to scripting. Scripting is done in VuGen. You can
learn more on how create, edit and enhance scripts in “VuGen Scripting for Web”
course.
1-12 The LoadRunner Scripting Component

Introduction
What is a Vuser?
Figure 1-9 The LoadRunner Vuser
Vusers emulate the actions of human users working with your application. While a
workstation accommodates only a single human user, many Vusers can run
concurrently on a single workstation.
What is a Vuser? 1-13

Introduction
Supported Protocols
Figure 1-10 Supported Protocols
Each type of Vuser is designed to handle different aspects of the system architecture.
Any combination of different types of Vusers can be used in a scenario to create a
comprehensive application test.
1-14 Supported Protocols

Introduction
What is a Scenario?
Figure 1-11 Elements of a scenario
Scenario
A scenario is a file that defines the scripts to execute, the number of Vusers to run,
the goals of the test, the computer that will host the Vusers, and the conditions
under which the load test runs.
Using LoadRunner, you divide your application performance testing

requirements into scenarios. A scenario defines the events that occur during each testing
session. For example, a scenario defines and controls the number of users to emulate the
scripts to run, the load testing goals to achieve, the machines on which they run their
emulations, and the settings with which they will run the load test.
What is a Scenario? 1-15

Introduction
What is the Controller?
Figure 1-12 The LoadRunner Controller
You use the LoadRunner Controller to manage and maintain your scenarios.
Using the Controller, you control all the Vusers in a scenario from a single workstation.
1-16 What is the Controller?

Introduction
LoadRunner Performance Monitoring
Figure 1-13 Analyzing performance
• Vuser scripts include functions that measure and record system performance during
load-testing sessions.
• During a scenario run, performance monitors are available for monitoring

application infrastructure components which provide metrics for system tuning.
• Following a scenario run, automatically generated performance reports provide a

statistical breakdown of results and analysis information you can view performance
analysis data in reports and graphs.
LoadRunner Performance Monitoring 1-17

Introduction
Why Use Performance Monitors?
Figure 1-14 The importance of performance monitors
All system components should be monitored in order to achieve effective Root Cause
Analysis. For instance, if you have two Web servers, monitor both of them. If you have
three database servers, then monitor all three. Monitoring all the system components
will help you to isolate performance problems in any part of your system environment.
1-18 Why Use Performance Monitors?

Introduction
Examples of LoadRunner Performance Monitors
Figure 1-15 Examples of LoadRunner performance monitors
Examples of LoadRunner Performance Monitors 1-19

Introduction
Putting it all Together
Figure 1-16 How LoadRunner components interact
Before proceeding further, let’s understand how the LoadRunner components work.
• Controller – Allows you to design Scenarios, run and stop the load test. Scenario
files have the .lrs extension.
• Load Generator – When a scenario is running, the results are, by default, stored
locally on each load generator machine. After the scenario has stopped running, the
performance data from each load generator machine is sent to the results file that
you have specified.
• Analysis – Processes the gathered scenario results and generates graphs and reports.
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.
1-20 Putting it all Together

Introduction
The Load Testing Process
Figure 1-17 The load testing process
Based on the results of the five phases of load testing, the application and related
hardware are typically adjusted and improved to boost performance. The same tests can
then be executed again to measure the application’s improvement in performance.
• Planning — Gather and document all relevant information about the

system for the load test.
• Create Vusers — Use the Virtual User Generator (VuGen) to automate user
actions of the selected business processes that you will test.
• Create Scenarios — Use LoadRunner’s Controller to set up the load test

environment by putting together the target hardware, the intended Virtual Users
(Vusers), and the conditions under which the load test will be run.
• Run Scenarios & Analyze Results — Run the load test and compile the results for
analysis using LoadRunner’s Controller. Use the analysis tools to organize and
display the results.
• Tune the System — Analysis of results should reveal areas of the system that
require adjustment. Once the adjustments are made, repeat the load test to
confirm that system adjustments had the desired effect.
The Load Testing Process 1-21

Introduction
LoadRunner Expert Workflow - The Big Picture
Figure 1-18 Overview of the load testing expert workflow
The LoadRunner Expert’s tasks and responsibilities extend to five phases of the load
testing process. Remember that successful load testing is a team effort, and you need to
rely on each of your teammates’ expertise to succeed.
1-22 LoadRunner Expert Workflow - The Big Picture

Introduction
LoadRunner Components in the Workflow
Figure 1-19 LoadRunner components in the workflow
LoadRunner Components in the Workflow 1-23

Introduction
Training Application for Web Protocol
B
t
I
S
P
S
Figure 1-20 Mercury Tours training site
From the Windows Start menu select START → PROGRAMS → MERCURY TOURS →
MERCURY TOURS.
Note: Before you access the training application, invoke the Apache server by selecting
START PROGAMS → START SERVER.
1-24 Training Application for Web Protocol

Introduction
Contents of this Course

Lesson 1 - Plan for an Effective Load Test
Lesson 2 - Install LoadRunner
Lesson 3 - Introduction to Scenarios
Lesson 4 - Using Run-time Settings
Lesson 5 - Scenario Execution
Lesson 6 - Scheduling Scenarios
Lesson 7 - Performance Monitors
Lesson 8 - Analyzing Results Data
In order to facilitate learning, the lesson order has been revised. In real life, you schedule
a scenario before it is executed.
Contents of this Course 1-25

Introduction
LoadRunner Resources
Books Online
• LoadRunner User’s Guide and Function Reference
Student Materials
• Student book, tips and tricks
http://support.mercury.com
• Worldwide User Community
• Self-help Features
– Mercury Interactive Knowledgebase (1000’s of solutions)
– Customer Knowledgebase
– User Discussion Forums (1000’s of Q&A topics each quarter)
• Submit/Update/Track Support Cases online
• Patches and Service Packs
• Product Alerts and Announcements
• Online Documentation
• Company Promotions and Customer Reward Program
1-26 LoadRunner Resources

Introduction
Summary
• LoadRunner enables you to automate application load testing.
• LoadRunner helps you locate and eliminate system bottlenecks.
• The load testing process consists of planning your load test, creating Vuser scripts,
creating your scenario, executing your scenario, and analyzing your results.
Summary 1-27
Introduction
Exercise: Product Overview

The topics just covered give an overview of load testing with LoadRunner. In this
exercise you will answer a series of questions dealing with LoadRunner components and
the load testing process.
1. Match the LoadRunner tasks with the LoadRunner components.
LoadRunner Tasks LoadRunner Components

Running Scenarios VuGen
Creating Vuser Scripts Controller
Creating Scenarios Analysis
Analyzing Test Results
2. What is the order in which the LoadRunner tasks should be performed?
_______________________________________________________________
3. Explain the role of Load Generator machines?
_______________________________________________________________
1-28 Exercise: Product Overview

Objectives
• Define measurable goals for your load test
• Gather preliminary information before load testing your system
• Organize system information effectively
• Use gathered information to plan load tests.
2-1
LoadRunner Expert Workflow - Establish Goals
Figure 2-1 Establish load test goals
2-2 LoadRunner Expert Workflow - Establish Goals

How to Define Goals

• When you define goals, the first step is to channel general application performance
expectations into conceptual goals.
– Conceptual goals should outline all of your load objectives
• Some examples of conceptual goals and their relative priority might include the
following:
– A high-priority example would be the responsiveness of a “Search” function.

Are we able to get search results within a reasonable time?
– A second example is the system administrator's concern that the “Update”

transaction functions well during heavy usage.
In the initial stages, jotting down unmeasurable goals will allow later filtering in order to
arrive at more focused goals, as well as to cover all objectives for load testing.
How to Define Goals 2-3

LoadRunner Expert Workflow - System Usage
Figure 2-2 Gather system usage data
2-4 LoadRunner Expert Workflow - System Usage

Gather System Usage Information

• By gathering system usage data you can:
– Decide which business processes to record
– Isolate peak loads and peak load times
– Document user actions and valid input data for each business process.
The first task is to understand the application to be load tested. This may involve:
• First-hand use of the site.
• Consultation with administrators to understand the nuts and bolts of the

infrastructure.
• Consultation with executives to understand the aspirations and

expectations of the site.
• Research of competing sites to understand the level of service in the

marketplace.
Gathering system usage data will help you determine business processes you need to
record, the expected response times, and the locations from which to monitor.
Gather System Usage Information 2-5

What is a Business Process?

Business Process
A business process is a set of actions or user steps performed within an application

to accomplish a business goal.
In the context of LoadRunner, it is a series of steps performed against the application

under test.
Just clicking a button is not a business process. It is only a step. A real business process
consists of taking an actual action such as finding information, making a purchase, or
changing an order.
2-6 What is a Business Process?

Examples of Business Processes
Figure 2-3 Business process examples
The individual tasks and functions performed by the users in the application are often
called business processes.
Model the business processes to emulate application functionality accurately.

Identifying business processes is crucial to designing realistic load test scenarios.
Examples of Business Processes 2-7

Anatomy of a Business Processes
Figure 2-4 Steps in a business process
• An alternative definition for business process is simply “a list of user actions.”
• In a flight booking application, a sign-in business process might consist of four

steps:
– Viewing the application’s main screen
– Typing the user name and the password
– Clicking the Sign-In button
– Viewing a screen that shows that the sign-in succeeded.
2-8 Anatomy of a Business Processes


Mission-Critical Transactions
Figure 2-5 Record mission-critical processes
Mission-Critical Business Process
Transactions that your business depends on.
Every mission-critical business process should be recorded and tested under load.
Mission-critical transactions for different applications vary
• Purchasing at an e-commerce site
• Searches at a search engine site
• Updated content display at a news site
• Downloading received orders or updating order status at a Client / Server system.
If you are unsure which processes are mission-critical, consult application experts or
your management team.
Business Processes to Record: Mission-Critical Transactions 2-9


Heavy Throughput Transactions
Figure 2-6 Record heavy throughput processes
Heavy Throughput
Business processes that may not be mission-critical but are very popular.
For instance, an internal search engine may be an important and frequently used tool,
even though it is not the primary reason for a user to visit the site.
The "heavily used" category also includes business processes associated with periodic or
sporadic traffic. For instance, a home page may receive heavy traffic immediately after a
marketing promotion. For Client / Server systems, login will receive heavy throughput.
2-10 Business Processes to Record: Heavy Throughput Transactions


Dynamic Content
Figure 2-7 Record processes with dynamic content
Any business process that relies on dynamic content is more likely to fail during periods
of heavy load than one based on static content.
Some examples include:
• Functions that require database lookup
• Dynamic page generation
• Streaming media broadcasting
• Making a call to the database
• CGI script execution.
Business Processes to Record Dynamic Content 2-11

Business Process Profile
Business
Dynamic Mission
Process Typical Day Peak Day Record
Content Critical
Name
Sign in 70/hr 210/hr Light High ?

Create new 10/hr 15/hr Moderate Low ?
account
Search for 130/hr 180/hr Moderate Moderate ?
flights
View flight 20/hr 30/hr Moderate High ?
booking
Purchase 40/hr 90/hr Heavy High ?
ticket
Table 2-1
2-12 Business Process Profile

Classroom Activity
Which business processes need to be recorded?
1. Choose a Web site, such as a ticket reservations site, E-commerce site, or one of
your production Web sites.
2. List all the business processes for the site.
3. Prioritize which business processes to record.
Chosen Web site:_________________________________________________
Business Process Names Recording Status
Classroom Activity 2-13

Measuring Steps
Figure 2-8 Measuring steps
How can you determine when testing goals are attained?
• LoadRunner allows us to define any number of elapsed time measurements for one
or more steps.
• Use time measurements as benchmarks to help you understand the performance of

your system under load and confirm goals related to transaction response time.
For example, you can validate a login function goal of 8-12 seconds by measuring the
elapsed time between the pressing of the "Sign-In" button and the appearance of the
results screen.
These types of measurements are called “Transactions.”
Once they are defined, the elapsed time will be recorded for every virtual user that
executes the script.
2-14 Measuring Steps

Measure Steps by Defining Transactions

LoadRunner Transaction
A LoadRunner transaction is an end-to-end measurement of time elapsed in the

execution of one or more steps in a business process.
– Transactions measure only the time spent on the servers, not the time spent on
the client.
– A transaction can consist of one or multiple consecutive steps.
– Transaction definitions can be nested inside one another.
– Any number of Transactions can be defined in a test.
Measure Steps by Defining Transactions 2-15

Preferred and Unacceptable Response Times
Figure 2-9 Categorize response times
The primary reason to do load testing is to improve the end-user experience by

minimizing response delays.
But what should be considered good performance? How much delay is acceptable? The
answer should be established for the most important steps of each business process.
Types of Response Times
• Preferred response time is the time the business process takes to complete under
ideal conditions.
• Preferred response time range is the time you want the business process to
complete, having taken slowdown factors into consideration.
Measurement criteria set by Preferred time allow us to keep a meaningful watch on the
application’s performance.
2-16 Preferred and Unacceptable Response Times

Documenting User Steps and Input Data
Figure 2-10 Logging in requires input (passwords) and steps (button push)
A business process is really just a series of steps. Some of these steps require the user to
input data. For instance, logging in to a Flight application usually requires two input
steps and a button push. Additionally, the input data must be recognized as valid for the
process is to succeed.
Documenting User Steps and Input Data
• Allows you to determine the navigation paths for the business processes
• Allows you to determine which user actions will utilize multiple data values
Document each step of each business process you selected for recording and
testing. An accurate documentation of these steps is important for recreating the test
cases and for identifying data sources, Transactions, and response times.
Documenting User Steps and Input Data 2-17

Determine Valid Test Data to Use
Figure 2-11 Determine valid test data
Record multiple sets of valid test data in a spreadsheet or document.
Multiple sets of valid test data:
• Allow you to emulate multiple real users by varying sets of input data
• Helps to avoid caching, unique data violations, and date constraints
2-18 Determine Valid Test Data to Use

Valid Test Data Sources

Valid input data comes from three sources:
• Master Data
– Also known as Application Data.
– Data is resident in the application’s database.
– Examples include ID numbers and passwords.
• User-Generated Data
– Originates with the user.
– Unique data for each execution of the business process.
– Examples include entering a new unique ID or email address.
• External Data
– Data is unknown before the application is run.
– Examples include confirmation and purchase order numbers.
Valid Test Data Sources 2-19

What is Think Time?

Think Time
LoadRunner Think Time is a measurement of the time that a real user takes to pause
between the execution of steps.
Users interact with an application according to their experience level and objectives.
• More technically proficient users may work very quickly.
• New users and those involved in certain kinds of business processes may proceed
very slowly.
By estimating these navigation times, virtual users can be made to emulate their real-
world counterparts more accurately during a load test.
2-20 What is Think Time?

Navigation Time Reflects User Pauses
Figure 2-12 Navigation time reflects user pauses
• Navigation Times
– Are included as Think Times in the load test
– Enable you to more accurately emulate real users.
Navigation Time Reflects User Pauses 2-21

What is a Concurrency?
Concurrency
A concurrency is a set of users acting upon an application in a similar manner at the

same time.
Concurrency occurs on three levels:
• Application Level
– How many users are active on the system?
• Business Process Level
– How many users are buying tickets?
• Transaction Level
– How many users are buying tickets now?
2-22 What is a Concurrency?

Application Concurrency
Figure 2-13 Application concurrency
A Task Distribution Diagram formats the business process and its volume across a time
line.
In the example above, the peak time is between 10am and 12pm on a typical day.
Formatting a TDD allows you to isolate usage peaks. In this example, the peak time is
outlined by the target time box. During this hour, the system experiences the heaviest
usage.
This is an important step in creating an effective load test. Testing your system under
peak load successfully ensures that the system can handle the load at other, less busy
times.
Testing your system under peak time will establish its baseline results. You should
increase the load in subsequent tests to test the scalability of your system.
Application Concurrency 2-23

Business Process Concurrency
Figure 2-14 Business process concurrency
Now that you know what your application can do, you can collect application usage, i.e.,
how users load your application at a given time. This will allow you to isolate the peak
time. The load that your system experiences is dynamic depending on the time of the
day.
For instance, e-commerce Web sites may experience heavy load during the lunch hour.
Conversely, an intranet application typically experiences heaviest load toward the end of
business hours. Consider, however, that usage can vary widely from one day to the next.
For example, a typical day will differ greatly compared to the days during the holiday
season. Due to this change in peak times, you should establish multiple baseline results
for system usage.
Note: Collect application usage for a typical day and also during heavy usage times like
holidays or promotions.
2-24 Business Process Concurrency

Transactional Concurrency
How many transactions will need to be run per minute if a load test has to be run for two
hours with 5000 users, assuming an average length of five minutes?
Determine how many transactions run per minute:
• 120 minutes / 5 minutes = 24 iterations for each user.
• 5000 users X 24 iterations = 120,000 transactions.
• 120,000 transactions / 120 minutes = 1000 transactions per minute.
Apply the transactional concurrency to the application (refer to the Application

concurrency figures):
• The test is run during the 10-12 AM time slot.
• The test should consist of 5000 users running 24 iterations.
• The system must be able to handle 1000 transactions per minute.
Transactional Concurrency 2-25

User Profile
Figure 2-15 Develop a user profile
Profiling Users:
• Helps emulate real world conditions.
• Provides tuning guidelines for the system.
• Increases customer satisfaction and revenue.
Users may vary enormously in terms of familiarity with the application, technical
knowledge, and objectives for using the application. Some users might be creating new
accounts; others might be searching an archive for old material. Think of user types as
simplified stereotypes defined by business processes. To emulate the real-world load
created by different types of users, the proportion of each type of user must be
determined.
Traffic at the Flight Reservation can be represented by three groups. "New users"
register and then browse the general content. "Potential travelers" typically browse
destinations. "Ticket purchasers" browse flights and then purchase tickets. An individual
starts out as a "New user." Then he/she may progress to one or more other categories,
such as "Ticket purchaser" or “Potential traveler." However, our interest is not in
tracking individual users. Instead, we want to understand the cross-section of all users
that use the application on a typical day. Once we have defined these groups by their
respective business processes, we can estimate what percentage of total users belong to
each group.
2-26 User Profile

Peak Load
Figure 2-16 Determine peak load
Business processes with the highest levels of load will be the most important to load test.
In this example the peak load for the Search BP is 5000 simultaneous users for the
period of 10:00 to 12:00.
For the purposes of this example you can define peak load as follows:
Peak Load
The number of users performing the business process during the busiest hours of the
busiest day.
Peak Load 2-27

Where are Your Customers Located?
Figure 2-17 Obtain customer locations
Customer Location
• May be obtained through software such as “Web Log.”
• May be obtained through an application’s customer registration database.
• Allows you to better emulate real-users.
• May be projected if the application has not yet been launched.
2-28 Where are Your Customers Located?

Transcontinental Remote Customers

Emulating remote network conditions:
• Do known or estimated WAN / Internet traffic conditions affect whether goals can
be met?
• Collect information from Network Administrators.
– Latency
– Packet loss
Planning for remote customers:
• Will remote customers be connecting over long distances via WAN and/or the
Internet?
• Will requests transit many hops over the network via servers over which we have no
control?
• How can a more accurate projection of connect times under real conditions be
projected for customers connecting from very remote locations that require a long
transit via the Internet?
• Is it impractical to place controllers at those remote locations?
• How will such network conditions as packet loss or latency be taken into
consideration when measurements are made?
• How will adjustments affect performance at re-testing?
Transcontinental Remote Customers 2-29

Quantifying Load Testing Goals
Figure 2-18 Quantify load testing goals
Now that we have gathered all necessary information for load testing, we can arrive at a
more focused, measurable goal. That will allow us to analyze the load test results and
define the success criteria for the application’s performance. Be sure to quantify each
conceptual goals.
For example, we can set a goal for ‘search’ of 8 seconds for average load and of no more
than 12 seconds during the peak hours. Remember we collected this information earlier
under ‘gather system usage information’.
For the second stated goal, 200 users should be able to ‘update’ records simultaneously
during peak time. State clearly that you are determining whether 200 users are
successful in updating the record at the same time during peak time.
2-30 Quantifying Load Testing Goals

LoadRunner Expert Workflow -

Analyze the System
Figure 2-19 Analyze the system under test
Load testing is about finding bottlenecks. This requires a detailed understanding of the
application under test.
LoadRunner Expert Workflow - Analyze the System 2-31

Analyze the System Under Test

Analyzing the System
• Allows you to setup LoadRunner monitors.
• Allows you to effectively coordinate with backend experts.
• Provides system information that helps isolate performance problems.
Sources of System Information:
• System Administrators
• Backend experts
• Application experts
• Database Administrators
2-32 Analyze the System Under Test

Understanding the System Components
Figure 2-20 System checklist
• System Checklists
– Provide a useful starting point
– Are limited in their ability to describe a system
– May be replaced by a system diagram
Understanding the System Components 2-33

Business Process Mapping to Infrastructure

Components
Figure 2-21 Map business processes to infrastructure components
• Business process flow
– Identifies the application components used by each business process.
– Identifies which components will be affected during a load test.
For example, if the Search process performs poorly under load as compared to the Home
Page process, identifying the bottleneck may just be a matter of knowing which
components each processes uses. Having this information during analysis will help us to
more easily isolate the bottlenecks.
2-34 Business Process Mapping to Infrastructure Components

Monitoring Application Components
Figure 2-22 Monitored components
Monitor all the components in your application.
Monitoring Application Components 2-35

Planning System Monitoring

Effective system monitoring involves answering key questions:
• Does the system have statistical information that will help in troubleshooting
performance issues?
• Who understands this information?
• Who can make changes to the system?
• Who has the appropriate security permissions for the system?
2-36 Planning System Monitoring

About the Test Environment

A test environment:
• Allows data to be written, read, and destroyed without affecting production users.
• Allows test systems to be rebooted during test runs without affecting production
users.
The test environment:
• Should mirror the production system
• Needs business processes that are functioning correctly before running the load test
• Should include Benchmark runs which validate the test environment
• Must contain sufficient hardware to generate the load test.
Note: Running an anti-virus while testing may prevent your load test from running
properly.
About the Test Environment 2-37

Benchmarking Run
To validate that there is enough test hardware available in the test environment,
benchmark the BPs against the testing hardware.
• Take a business process and execute a small number of users against the
application.
– Validates the functionality of the BP
– Potentially exposes unknown data dependencies
– Establishes the user footprint
• Evaluate the testing infrastructure against the footprint.
– Do I have enough hardware to generate the user load?
– Do I have enough memory?
– Do I have enough CPUs?
Note: The following sights provide additional information on running benchmarks in a

test environment.
Guidelines for optimizing system performance for Vusers on Windows NT 4.0
through hardware and operating system tuning - refer to Customer support knowledge
base, ID 3629 for detailed info.
Determining the number of Vusers that can run on a Load Generator - for more info
on this refer to online documentation and to knowledge base ID 11808.
Vuser memory requirements (memory footprints) - for more info on this topic refer to
knowledge base article ID 10291.
2-38 Benchmarking Run

Summary
• Planning should be done before you start recording.
• Proper planning increases test coverage and reduces test development time.
• Understanding testing objectives helps build effective and measurable load tests.
• Document all relevant test information before building your load tests.
• Run your load tests in a test environment.
Summary 2-39
Exercise: Planning an Effective Load Test

The topics just covered give an overview of planning a load test. In these exercises you
will perform planning tasks and answer a series of questions that reinforce the concepts
and skills needed to properly plan load tests.
MERCURY TOURS User Steps Table

(used for lab exercises)
STEP DESCRIPTION EXPECTED RESULT
0 INITIAL CONDITIONS Browser displays Mercury Tours

home page.
1 Type the user name and password into the Name: jojo
Mercury Tours Web site. Password: bean
2 Click "Sign-in." After logging in successfully, the
Flight Finder page appears.
3 Select "1" from the Passengers list.
4 Select "Seattle" from the Departing From
list.
5 Select "Sydney" from the Arriving In list.
6 Select "First class" from the Service Class
group.
7 Click "Continue". The Select Flight page appears.
8 Click "Continue” to accept the default flight The Book a Flight page appears.
selections.
9 Type "Joseph" in the First Name box under
Passengers.
10 Type "Williams" in the Last Name box under
Passengers.
11 Select "MasterCard" from the Credit Card
Type list.
12 Type "12347890" in the Number box.
13 Specify the expiration date as "10" and
"2006" in the Expiration section.
2-40 Exercise: Planning an Effective Load Test

STEP DESCRIPTION EXPECTED RESULT
14 Click "Secure Purchase". The Flight Confirmation page

appears with a success message and a
confirmation number.
15 Click "Back to Home" to reset the initial con- The Mercury Tours home page
ditions. appears.
Exercise A: Preliminary Setup

Part 1: Start the Server
1. Start the Server.
a) From the Windows Start menu, select START SERVER from the Mercury Tours
program group.
b) Verify that the START SERVER window displays the following line:
Apache/1.3.17 <Win32> ApacheJServ/1.1.2 running...
c) After verifying, minimize the window.
Note: ALWAYS use the Stop Server process (either from the Desktop icon or from the
Start menu Programs > Mercury Tours) to stop the Apache Web server. If you shut the
server down some other way, unexpected results may occur.
Part 2: Start the Training Application
1. Invoke the browser.
a) Bring up the Mercury Tours Web site.
b) In the URL space, type the URL of the training Web site:
http://localhost/servlets/com.mercurytours.servlet.WelcomeServlet
c) Press ENTER.
The Mercury Tours Web site should come up. Mercury Tours will be the
application under test. Familiarize yourself with Mercury Tours by performing the
steps listed under “MERCURY TOURS User Steps Table” above.
Exercise B: Planning
Before you begin load testing, answer the following questions to test your understanding
of the Planning lesson.
Exercise: Planning an Effective Load Test 2-41

Identify all the sub-business processes from the “MERCURY TOURS User Steps
Table” that fit the business process definition discussed in this chapter.
__________________________________________________________________
______
List the user steps that require input data for the identified business processes.
Step Numbers (identified as Input data (yes or no)

business process)
What are the criteria for determining which business processes should be recorded?
__________________________________________________________________
________________________________________________________________
Analyze the chart below. Based on this chart, which business processes will you
choose to record?
__________________________________________________________________
Business Typical day Peak day Database Mission

process name activity critical
Sign in 70/hr 210/hr Light High
Create new 80/hr 140/hr Moderate High

reservation
Search for flights 130/hr 180/hr Heavy Mod.
View flight
booking 20/hr 30/hr Moderate High

Examine the TDD (Task Distribution Diagram) below and determine the peak
time.
__________________________________________________________________
Task Distribution Diagram for Mercury Tours site:
Business
Processes
Create new account Night 40 30 Day50 100 50 50 25 120 Night
Search for flights 2000 5000 1500 1000 500 5500
View flight booking 700 1600 500 300 150 2000
Purchase ticket 500 200 170 140 750
Administrative
Processes
Invoice 50 50 50 50
processing
System backup 1 1
12 2 4 6 8 10 12 2 4 6 8 10 12
am pm am
FLIGHT RESERVATION (typical work day)

Review Questions
Test your understanding of this lesson by answering the following questions:
Why should you gather end-user navigation times?
__________________________________________________________________
__________________________________________________________________
How does knowledge of business process flow help you?
__________________________________________________________________
__________________________________________________________________
Why is gathering input data important?
__________________________________________________________________
__________________________________________________________________

Sample LoadRunner Planner to Help You Plan Your Load Tests

SECTION A: GOALS
Note: The section which follow provide sample planning forms. The forms are not
intended as exercises.
1. Write down your conceptual goals for this load test.
Conceptual Goals Quantitative Goals
Primary Goal
Secondary Goals
Additional Goals

SECTION B: SYSTEM UNDER TEST
2. Document all the business processes performed in your application.
Business Process Description

3. For each user profile, indicate the associated business processes and percentage of
total users. The percentages should tally to 100%.
4. Estimate navigation times.
User Profiles Description Total Users (%) Business Processes Average Navigation
Times
Total 100%
Table 2-1.

5. For each business process, estimate the average and peak number of simultaneous
users. In other words, how many users are performing each process in a typical day
and in the heaviest periods?
6. For each business process, indicate which are mission critical, which experience
heavy throughput, and which feature dynamic content.
7. Based on these criteria and the lesson, determine which processes to record.
Business Process Average Number Peak Number Mission Heavy Dynamic Record
of Simultaneous of Critical? Through- Content? This
Users Simultaneous put? Process?
Users
V V V V
V V V V
V V V V
V V V V
V V V V
V V V V
Table 2-2.

8. For each selected business process, document user steps and determine whether the
step requires input data. If so, indicate the data source.
Business User Steps Input Input Data Add Response Times

Process Data? Source Transaction?
Preferred -
V V
Unacceptable -
Preferred -
V V
Unacceptable -
Preferred -
V V
Unacceptable -
Preferred -
V V
Unacceptable -
Preferred -
V V
Unacceptable -
Preferred -
V V
Unacceptable -
Table 2-3.

SECTION C: SYSTEM CONFIGURATION
9. Fill out as much of the system configuration table for each component as possible.
Web Servers
Quantity Server Software Hardware Specs OS
Application Servers
Database Servers
Firewalls Load Balancers
Quantity Type Quantity Type Scheme

10. For each business process, indicate the servers that are exercised by the process.
Web Application Database

Business Process Servers Servers Servers
V V V
V V V
V V V
V V V
V V V
V V V
11. Return to Section A Step 1 and specify quantitative goals.
12. Return to the table in Section B Step 7 and determine where — based on the
quantitative goals — LoadRunner transactions should be added.
13. In the same table, indicate preferred and unacceptable response times for each
LoadRunner transaction added.

SECTION D: The Scenario
14. For each goal, indicate the following:
Scenario Quantitative User Profile or Number of Host Machines Navigation Time

Goal Vuser Scripts Vusers (Load Generators) (Think Time)
Table 2-4.

Installation
Installation
Objectives
• Describe the LoadRunner architecture
• Determine where to install LoadRunner components
• Identify hardware and software needed for installation.
3-1
Installation
LoadRunner Expert Workflow - Installation
Figure 3-1 LoadRunner expert workflow - installation
3-2 LoadRunner Expert Workflow - Installation

Installation
Where Do I Start?
• Check your LoadRunner package for the software CD and a set of documentation
• Register your copy of LoadRunner
– online at http://support.mercuryinteractive.com
– by mail using the Mercury Interactive software registration card
Where Do I Start? 3-3

Installation
Where to Install Each Component
Figure 3-2 Where to install each component
Before proceeding further, let’s understand how the LoadRunner components work.
• VuGen (Virtual User Generator) – Allows you to create scripts. These scripts
emulate human users on playback.
• Controller – Allows you to design Scenarios, run and stop the load test. Scenario
files have the .lrs extension.
• Load Generator – When a scenario is running, the results are stored locally on each
load generator machine by default. After the scenario stops running, the
performance data from each load generator machine is sent to the results file that
you have specified.
• Analysis – Processes the gathered scenario results and generates graphs and reports.
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 .lrr. After the results
are processed by the Analysis tool, the file is saved as .lra.
3-4 Where to Install Each Component

Installation
Installing VuGen
Figure 3-3 Installing VuGen
• Install VuGen on a PC that has access to the application to be scripted
• Verify that the PC hosting VuGen can open the application to confirm proper setup
Installing VuGen 3-5

Installation
Installing the Controller
Figure 3-4 Installing the Controller
• Install the Controller on a PC with connectivity to the load generators.
• LoadRunner license keys are installed on the Controller and locked to the computer
by a Host ID.
• The license key controls the number and type of virtual users and the type of
monitors that can be used in the Controller.
Note: The Controller can only be installed on a Windows platform.
3-6 Installing the Controller

Installation
Installing Load Generators
Figure 3-5 Installing load generators
• Load Generators are installed from wherever users access the application under test.
• Load Generators are installed as LoadRunner Agents, which can be a process or

service.
• A scenario may employ one or more Load Generators.
• A Load Generator can be employed by only one Controller at a time.
• Load Generators need connectivity to both the Controller and the AUT (application
under test).
• A load generator must be installed on the Host machine.
Note: You must have administrative privileges to run LoadRunner on your machine.
Automatic login (selected during the LoadRunner install) determines whether the
LoadRunner Agent runs as a process or as a service.
Installing Load Generators 3-7

Installation
Install Load Generators to Reflect Customer

Base
Figure 3-6 Installation reflects customer base
If you have a significant customer base at different locations, consider installing Load
Generators at these locations.
This emulates human users accessing your application from these locations.
3-8 Install Load Generators to Reflect Customer Base

Installation
WAN Emulation
Figure 3-7 WAN emulation
Wan Emulation
• WAN emulation software mimics the WAN/Internet by slowing, dropping, and

changing packets between client and server.
• Should be installed on all load generator machines (requires a separate install and
license).
WAN Emulation 3-9

Installation
Why Emulate Remote Users Performance?

• Realistically emulate remote-user response time.
• Find out if the application is able to handle the WAN/Internet packet loss and
latency behavior.
• WAN/Internet conditions affect overall performance.
• Discover how certain elements affect the performance of your site when remote
users connect.
– Network latency
– Packet loss
– Packet duplication
– Packet fragmentation
– Bit error rates
3-10 Why Emulate Remote Users Performance?

Installation
WAN Emulation - procedure

WAN Emulation is a separate install process and requires a special license. The product
is installed from the Start menu in the LoadRunner/Tools hierarchy. Contact Mercury
Interactive’s Customer Support Web site for licensing.
WAN Emulation is available only for load generators running on a Windows platform.
Access it from the Load Generator Information dialog box and select the WAN
Emulation tab.
You can change WAN emulation settings only while a load generator is in the Down
status.
1. Select the load generator and click Disconnect.
The load generator status changes to Down, and you can change the settings. The load
generator cannot be a localhost; it must be a remote machine.
WAN Emulation - procedure 3-11

Installation
Installing Analysis
Figure 3-8 Installing Analysis
• LoadRunner Analysis can be installed anywhere and on as many machines as

needed, provided the Controller has visibility to the Analysis machine
• When selecting hardware for installing Analysis:
– Keep in mind the number of test runs you plan to make (the more test runs the
more disk space required).
– Think about how long the test data needs to be stored (the amount of stored and
new data needs to be taken into account).
3-12 Installing Analysis

Installation
Putting it all Together
Figure 3-9 Putting it all together
Putting it all Together 3-13

Installation
Minimum Hardware Recommendation
Figure 3-10 Minimum hardware recommendation
The hardware should be powerful and fast enough to emulate the required
number of virtual users.
To decide on the number of machines and correct configuration, consider the

following:
• It is advisable to run the LoadRunner Controller on a separate machine.
• When selecting the machine for Analysis, keep in mind how many Load Generator
machines are running.
• For more info on system requirements, check
http://www.mercury.com/us/products/performance-
center/loadrunner/requirements.html
3-14 Minimum Hardware Recommendation

Installation
Need for Remote Infrastructure

To test an outside firewall use Mercury Interactive’s Performance Validation and
Optimization Service located at:
http://www.mercury.com/us/services/managed/performance-center
Performance Validation and Optimization is a hosted, Web-based service

powered by the industry-standard load testing tool, LoadRunner. Performance
Validation and Optimization uses real-time monitors to measure response times for
business processes and to gather metrics on all components within a Web infrastructure.
With this data, Performance Validation and Optimization experts can identify
performance bottlenecks inside and outside the firewall and begin to pinpoint their
causes. As a hosted service, Performance Validation and Optimization provides all the
resources and expertise needed to load test Web applications.
Need for Remote Infrastructure 3-15

Installation
Verifying Connectivity to a Load Generator

It is always a good practice to verify the connectivity of load generators once you add a
new load generator to the scenario. This will allow you to eliminate any connectivity
problems before running a load test.
To verify connectivity from the Controller to a Load Generator:
1. Open a scenario in the Controller.
2. In the DESIGN tab, click the GENERATORS button.
3. Click ADD GENERATOR. You will need one of the following:
– PC Netbios (Windows) name
– DNS name
– IP address
Note: The best practice is to use the PC Netbios or DNS name.
4. Select the appropriate operating system and a valid path for temporary storage.
5. Attempt to connect to the generator. (“Ready” appears if successful.)
3-16 Verifying Connectivity to a Load Generator

Installation
Troubleshooting Generator Connectivity Issues

• Verifying connectivity
– Ping generator by name/DNS/IP
• Confirm the LR Agent is running (Windows)
– Radar dish in System Tray of generator PC
– Remotely, magentservice.e process or magentservice.e service will appear in

Task List of the generator PC
• Confirm that LR Agent Process is running (Unix)
– Remotely, m_agent_daemon or m_agent_process will appear in generator PC
• Is a Firewall blocking access?
– See LoadRunner technical document #11279 describing LoadRunner

configuration for firewalls on:
– Also refer to Appendix C in the student book
Troubleshooting Generator Connectivity Issues 3-17

Installation
Summary
• Three main software components of LoadRunner are:
– VuGen
– Controller
– Analysis
• Careful planning is required when installing LoadRunner components to ensure

proper functionality.
• Hardware capacity must match LoadRunner’s requirements.
3-18 Summary
Installation
Exercise: Installation
The topics just covered give an overview of LoadRunner installation. In this exercise
you will add and connect load generators, then answer a series of questions dealing with
LoadRunner components and the installation process.
Exercise A: Troubleshooting
Part 1: Adding Load Generators and Connecting Them
1. Write down the network name of your partner’s computer.
Network computer name: ______________________________________
To get your partner’s network computer name:
Windows NT
a) Right-click the Network desktop icon and select “Properties” from the pop-up
menu. The machine name appears in the Properties dialog.
Windows 2000
b) Right-click the My Computer desktop icon
c) Select “Properties” from the pop-up.
d) Click the Network Identification tab to see the name.
2. Invoke the Controller on your machine.
a) From the WINDOWS START menu, select MERCURY LOADRUNNER →

LOADRUNNER. This will launch the LoadRunner main screen / launcher.
b) Under the LOAD TESTING tab, click the RUN LOAD TESTS link. This will open
the LoadRunner Controller.
3. Display the Scenario Schedule and Scenario Groups panes.
a) Click OK on the NEW SCENARIO dialog. The Controller DESIGN tab opens,
displaying the SCENARIO SCHEDULE and SCENARIO GROUPS panes.
4. Add your workstation as a Load Generator.

a) Click on the GENERATORS button. This opens the LOAD GENERATORS dialog.
Exercise: Installation 3-19

Installation
b) By default, this will have the localhost added as your generator. Change the name to
your machine’s network name.
c) Do not close the Load Generator dialog.
5. Add your partner’s machine as the second Load Generator.

a) Click the ADD button. The ADD NEW LOAD GENERATOR dialog box opens.
b) In the NAME box, type the partner’s machine name you wrote down in the first step of
this exercise.
c) In the PLATFORM list box, select WINDOWS and then click OK.
6. Connect the Load Generators
a) Select the machines that you just added one at a time and click the CONNECT button.
b) Make sure that the load generator status in the STATUS changes to “Ready” for the
load generators.
3-20 Exercise: Installation

Installation
Part 2: Stop the LoadRunner Agent Process
To perform Part 2 of the exercise, move to your partner’s computer.
1. Stop the LoadRunner Agent Process on your partner’s machine.
a) Right-click on the dish icon located on the system tray.
b) Select Close to stop the LoadRunner Agent Process.
Part 3: Status of the Second Load Generator
1. Check the status of the second generator on your machine.

a) Return to your workstation.
If Load Generator dialog is not open do this:
b) Click on the GENERATORS button. This opens the Load Generators dialog.
What is the status of the second generator?
__________________________________________________________________
______
Explain the message that you received for the second generator.
__________________________________________________________________
______

Installation
Part 4: Restarting the LoadRunner Agent
1. Invoke the LoadRunner Agent Process.
a) Move to your partner’s machine.
b) From the WINDOWS START menu, select MERCURY LOADRUNNER →

LOADRUNNER AGENT PROCESS.
2. Reconnect to the second load generator machine.
a) Move to the first computer.
b) Select the second load generator machine and click the CONNECT button. The
load generator status in the STATUS changes to “Ready”.
c) When you are done, close the Scenarios - no need to save.
Exercise B: Installation
One task of a LoadRunner expert is to educate the system and database
administrators about the location where the LR components are to be installed, the
quantity and type of hardware needed, and the data flow between LR components.
In this exercise, the customer base is highly concentrated in San Francisco and New
York. The application to be tested is located in San Francisco.
Components that the company has purchased and needs to install are:
– VuGen
– LoadRunner Controller
– LoadRunner Analysis
– Load Generators
1. In which of the following locations would you place load generators?
a) New York
b) San Francisco
c) New York and San Francisco
d) Kansas City

Installation
2. Draw a schematic of the system architecture including all the components

mentioned above.
3. What things do you need to keep in mind when deciding on the hardware
requirement for a LoadRunner installation?
__________________________________________________________________
_______________________________________________________
Review Questions
How many Controllers must be installed in order to conduct a load test?
________________________________________
_What factors determine the locations for load generators?
___________________________________________

Installation

Objectives
• Explain the elements that make up a LoadRunner scenario
• Identify the different types of scenarios
• Choose scenario type based on your quantitative goals
• Present the basic steps for creating a scenario.
4-1
LoadRunner Expert Workflow - Understanding

Scenarios
Figure 4-1 Understanding scenarios
4-2 LoadRunner Expert Workflow - Understanding Scenarios

What is a Scenario
Figure 4-2 Scenario definition
Scenarios define the overall load test execution.
• Which scripts are to be executed?
• How many virtual users will execute each script, and how suddenly or gradually
should they begin?
• Which load generators will host the Vusers?
• What is the goal of the load test?
What is a Scenario 4-3

The LoadRunner Controller
Figure 4-3 The LoadRunner Controller
The Controller organizes and manages the scenario elements
• Before scenario execution
– used to design the scenario
– used to initiate the scenario run
• During scenario execution
– controls each Vuser (initialize, run, pause, stop)
– displays the execution status and messages of each Vuser
– monitors system and network resources
• After scenario execution
– collects and organizes performance data
– launches the Analysis tools (optional)
4-4 The LoadRunner Controller

Scenario Outline - Examples
Figure 4-4 Examples of scenario outlines
• The Scenario Outline incorporates Quantitative goals (Controller goals) into the
scenario design
• Controller goals define the scenario in terms of actual measurements
– number of Vusers
– pages per minute
– transaction per second
– transaction response time
For example, if the goal is "2000 concurrent users able to buy tickets at the same time,"
the objective could be satisfied with a 'Buy Ticket' script in a 'number of Vusers'
scenario.
Scenario Outline - Examples 4-5

Creating a New Scenario
Figure 4-5 Creating a new scenario
You use the commands in the File menu to create, open, save, and close scenario files.
To create a new scenario, choose FILE > NEW, or click the NEW button on the
Controller toolbar. The NEW SCENARIO window will open. From here select either
Manual Scenario or Goal-Oriented Scenario.
Note: The NEW command creates a completely new scenario. Note that this command
clears all the information displayed in the Controller windows.
4-6 Creating a New Scenario

Select Vuser Scripts
Figure 4-6 Select Vuser scripts
Adding scripts to the Scenario

1. Select a script from the AVAILABLE SCRIPTS list.
2. If a script is not visible in the AVAILABLE SCRIPTS list:
a) Click BROWSE and navigate to the script location.
b) Select the script to add it to the Available Scripts list
3. Click ADD to include it in the SCRIPTS IN SCENARIO pane.
4. Click OK. The scenario opens in the Controller with the selected scripts included.
Note: The Remove button will eliminate the script from the scenario but not from the
file system.
Select Vuser Scripts 4-7

Vuser Groups
Figure 4-7 Controller window with Vuser groups
A Vuser group is a collection of Vusers within a scenario.
• A scenario consists of groups of Vusers which emulate human users interacting

with your application
• Each group can be assigned a different script to emulate different business process
• Create Vuser groups from the Scenario Groups pane of the Controller
• Vuser groups serve various functions
– Organizing vusers into manageable groups
– Representing different “User Profiles”
– Exercising specific components within the test application
4-8 Vuser Groups

Adding a Vuser Group
Figure 4-8 Adding a Vuser group
1. Click the ADD GROUP button to the right of the Scenario Groups pane. The ADD
GROUP dialog box opens.
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. Click OK to close the ADD GROUP dialog box. The new group’s properties appear
in the SCENARIO GROUPS pane.
Adding a Vuser Group 4-9

Modifying the Vuser Group Settings
1. Modifying Vuser group settingsSelect the Vuser group whose settings you want
to change and click the DETAILS button.
This will open the Group Information dialog displaying all the information about
that group. You can change the Group name, load generator name, Vuser
quantity, and Run-time Settings of the script.
2. Once you have modified the necessary settings, click OK. This will update the
changes for that Vuser group.
4-10 Modifying the Vuser Group Settings

Manual vs. Goal-Oriented Scenarios
Figure 4-9 Select a manual or goal-oriented scenario
Manual Scenario
• Manual control over how many Vusers run and at what times.
• Add, start, and stop Vusers interactively during a scenario run.
Goal-Oriented Scenario
• Goal may be throughput, response time or number of concurrent Vusers.
• LoadRunner manages Vusers automatically.
• Cannot add, start, or stop Vusers interactively during a scenario run.
Manual vs. Goal-Oriented Scenarios 4-11

Which Scenario Type to Choose? Example
Figure 4-10 Choosing a scenario type
4-12 Which Scenario Type to Choose? Example

Selecting Load Generators for your Scenario
Figure 4-11 Selecting load generators for your scenario
• Add load generators to the locations selected during planning
• Your user profile and the customer location will give you the answer for selecting
locations for the load generators
Selecting Load Generators for your Scenario 4-13

Adding a Load Generator
Figure 4-12 Adding load generators
Add the load generators
1. Click the GENERATORS button, or select SCENARIO→ LOAD GENERATORS from

the menu.
The Load Generators dialog box opens. The Name of the load generator, its
Status, Platform, and Details are displayed.
2. Click the ADD button to add a new generator. The Add Load Generator dialog box
opens.
4-14 Adding a Load Generator

Defining a New Load Generator

.
Figure 4-13 Add New Load Generator dialog box
1. Type the name of the load generator in the NAME box.
2. In the PLATFORM box, select the type of platform on which the load generator is
running.
3. Click OK
Defining a New Load Generator 4-15

Connecting to a Load Generator
Figure 4-14 Connect to the load generators
This is an optional step. When you issue the Run command for scenario execution, the
assigned load generators will automatically connect. You can use this step to test if load
generators are connecting correctly.
Click CONNECT to change the Status of the load generator from “Down” to “Ready”.
It is a good practice to always connect the load generators once you add them.
4-16 Connecting to a Load Generator

Configuring Load Generator Settings
Figure 4-15 Configuring load generator settings
1. Click the GENERATORS button, or select SCENARIO → LOAD GENERATORS to

open the Load Generators dialog box.
2. Click the DETAILS button. The LOAD GENERATOR INFORMATION dialog box opens.
Do not confuse this Details button with the one available on the Scenario Groups
screen. This one allows you to modify Vuser group settings.
The Load Generator Information dialog box allows you to configure settings for
individual load generators.
To learn more about the options for, configuring load generators, refer to the
LoadRunner books online (Controller User’s Guide under Designing a
Scenario topic).
Configuring Load Generator Settings 4-17

Assigning User Profiles to Load Generators

Answer these questions before assigning the user profiles to load:
• Do all locations serve the same function?
– Which locations perform order entry?
– Which locations perform shipping?
– Which locations perform customer service processes?
Before you begin to assign scripts / user profiles to load generators, it is critical to go
back to the planning chart and ask the above mentioned questions. Each question will
have a preceding concern to answer. For example, you may find that a concentration of
new users is found in the vicinity of San Francisco. So we will assign the script that
performs the business process or processes that a new user performs to the load
generator located in San Francisco.
Going back to the planning document and determining which ‘User Profiles’ best
represent the load generator’s location will allow you to assign the right scripts to the
load generators.
4-18 Assigning User Profiles to Load Generators

Assigning User Profiles to Load Generators -

Example
Figure 4-16 Assigning user profiles to load generators
Determine the user profile that will best represent the cross-section of business process
activity for the load generator location. Based on the findings, assign the selected “User
Profile” to that location.
Assigning User Profiles to Load Generators - Example 4-19

Assigning Number of Vusers
Figure 4-17 Assigning Vusers to scenarios
• Simple Scenarios
– Have a single user script.
– Assign 100% of Vusers to the script to profile a group of users performing the
same action.
• Multiple Script Scenarios
– Use several scripts.
– Assign a percentage of the total Vusers to each profile.
4-20 Assigning Number of Vusers

Summary
• Create Scenarios around quantitative goals.
• Choose Manual or Goal-Oriented Scenario type based on test goals.
• A Scenario defines the events of a load test.
• LoadRunner Controller organizes and manages Scenarios.
Summary 4-21
Exercise: Introduction to Scenarios

The topics just covered give an introduction to scenarios. In this exercise you will create
and run your own scenario.
Exercise A: Understanding Scenario Creation

1. Choose the appropriate scenario outline, given the following for the quantitative
goal:
Quantitative Goal: Attain 1,000 concurrent users for the Search transaction during
peak time.
a) Load test should achieve 1,000 users.

b) Script should define ‘search’ transaction and load test should achieve 1,000
users at peak time.
c) Script should define ‘search’ transaction and load test should achieve 1,000
concurrent users at peak time.
__________________________________________________________________
______
2. Choose the appropriate scenario type, given the following Scenario outline:
Scenario Outline: Script should define ‘search’ transaction and load test should
achieve 1,000 concurrent users at peak time.
a) Manual Scenario
b) Goal-Oriented Scenario
c) Both
Explain your answer.
_________________________________________________________________
Assigning Load Generators
3. A client has significant customer base in Seattle, Paris, and New York. There are
three load generators installed at each location. Gathered information shows:
• Seattle customers are typically performing the Update business process
• Paris customers are new users.
• New York customers show more purchasing activity.
4-22 Exercise: Introduction to Scenarios

The scripts recorded are:
– Register
– 2. Update
– 3. Buy
4. Based on the limited information available, how will you approach assigning scripts
to the load generators?
________________________________________________________________
__________________________________________________________________
5. Will you assign particular scripts to some load generators, or will you assign all the
scripts to all the load generators?
________________________________________________________________
__________________________________________________________________
Exercise: Introduction to Scenarios 4-23

Exercise B: Scenario Creation

For this exercise and other exercises in this course you will use an existing script,
BookFlight located in the directory c:\training\loadrunner\Scripts.
The BookFlight script logs on to the Mercury Tours training Web site with registered
user name and password. Once log on is successful, the script performs the action of
buying a ticket and logs out of the site. The script is configured to perform these steps by
four different users. Please review the script with your instructor before moving forward
with the exercise.
Part 1: Invoke Apache Web Server
1. Start the Windows Task Manager program.
a) Right-click the Windows task bar and select TASK MANAGER.
Make sure the Apache Web Server is running. The START SERVER icon should
appear on the Windows Task Bar. If you do not see it, check Task Manager’s
Applications tab. START SERVER should appear there also.
2. If Apache is not running, start the Server:
a) From the Windows Start menu, Mercury Tours select “Start Server”.
b) Verify that the Start Server window displays the following line:
Apache/1.3.17 <Win32> ApacheJServ/1.1.2 running...
c) After verifying, minimize the window.
Note: ALWAYS use Stop Server (either from the Desktop icon or the Start menu
PROGRAMS → MERCURY TOURS) to stop the Apache Web server. Shutting it down by
other methods may result in unexpected results.
Part 2: Create a Scenario
1. Invoke the Controller. If the LoadRunner Controller is already open, then move to
step two.
a) From the Windows Start menu, select LOADRUNNER from the Mercury
LoadRunner program group. This will launch the LoadRunner main screen /
launcher.

2. Create a manual scenario.

If the New Scenario dialog did not appear automatically after you invoked the Controller or if
the Controller is open:
a) Select FILE → NEW or click the CREATE A NEW SCENARIO button to

open it.
b) In the SELECT SCENARIO TYPE pane, select MANUAL SCENARIO.
c) Make sure that USE THE PERCENTAGE MODE. . . is unchecked.
3. Add the BOOKFLIGHT script to the scenario.
a) Select BOOKFLIGHT from the Available Scripts list and click the ADD
button. .
b) If BOOKFLIGHT is not in the list, click BROWSE and navigate to

\training\loadrunner\Scripts to find it.
c) Click OK. The Controller DESIGN tab opens, displaying the Scenario Schedule
and Scenario Groups panes.
Part 3: Create Vuser Groups
1. Rename the group to scenario_groupa.
a) Click the Details button. The Group Information dialog opens.
b) In the Group Information dialog box, overwrite the text in the Group Name box
with scenario_groupa.
2. Add 10 Vusers.
a) In the Quantity box, overwrite the default number with 10.
b) Click OK to close the Group Information dialog.

3. Create another group named scenario_groupb and add 15 Vusers
a) Click ADD GROUP button to open the ADD GROUP

dialog.
b) In the GROUP NAME box, overwrite the text with scenario_groupb.
c) In the LOAD GENERATOR NAME box, make sure localhost is selected.
d) In the VUSER QUANTITY box, make sure 15 is selected.
e) Make sure SCRIPT NAME is showing BookFlight, if not then select

BookFlight script.
f) Click OK to close the Add Group dialog.
Part 4: Run the Scenario
1. Verify that Auto Load Analysis is not enabled.
a) Click the RESULTS → AUTO LOAD ANALYSIS toolbar button to disable the
analysis from opening after a test run.
2. Specify the result file: \training\loadrunner\Results\scenario_intro.
a) Select RESULTS → RESULTS SETTINGS. The Set Results Directory dialog box
opens.
b) Type scenario_intro in the RESULTS NAME box.
c) If c:\traing\loadrunner\Results is not the default directory, then click

BROWSE and select it.
d) Click OK to close the Set Results Directory dialog box.

3. Run the scenario.
a) Click the START SCENARIO button in the Design tab to run

the scenario.
4. Observe the SCENARIO GROUPS pane.
When the Scenario runs, the tab changes automatically from DESIGN to RUN.
a) Observe the Scenario Groups pane.
b) Watch or note down what stages Vusers are going through.

5. Save the scenario.
a) Save the scenario as:

\training\loadrunner\Scenarios\scenario_intro.lrs.
What option will you use to configure settings on individual load generators?
__________________________________________________________
Part 5: Configure Load Generators
1. Configure the load generator to initialize 5 Vusers for the both the groups.
a) Click the DESIGN tab.
b) Click the GENERATORS button . This opens the LOAD

GENERATORS dialog box.
c) Select the load generator that you added in your scenario, default is localhost.
d) Click the DETAILS button, this will invoke the LOAD GENERATOR
INFORMATION dialog.
e) Click on RUN-TIME QUOTA tab.
f) In the NUMBER OF VUSERS THAT MAY BE INITIALIZED AT ONE TIME box

enter 5.
f) Click OK to close the Load Generator Information dialog.
g) Click CLOSE to shut the Load Generators dialog.
Part 6: Run the Scenario Again
1. Specify the result file: \training\loadrunner\Results\scenario_introLG.
a) Select RESULTS → RESULTS SETTINGS. The SET RESULTS DIRECTORY dialog

box opens.
b) Type scenario_introLG in the RESULTS NAME box.
c) If c:\training\loadrunner\Results is not the default directory, then click


2. Run the scenario again.

a) Click the START SCENARIO button in the Design tab to run

the scenario
3. Observe the SCENARIO GROUPS pane.
When the Scenario runs, the tab changes from Design to Run automatically.
a) Observe the Scenario Groups pane to see stages the Vusers go through. More
on the Vuser stages will be discussed in the Scenario Execution lesson.
Explain what you observed when the scenario ran without initialization as
compared to with initialization options enabled?
__________________________________________________________________
_________________________________________________________
Review Questions
What is the role of the LoadRunner Controller?
_____________________________________________
What factors should determine which scripts are assigned to load generators?
____________________________________

Objectives
• Explain the difference between Script and Scenario Run-time settings
• Configure Run-time settings based on load testing goals.
5-1
LoadRunner Expert Workflow
Figure 5-1 LoadRunner expert workflow
Before you run a scenario, you can configure both the load generator and
Vuser behaviors for the scenario. Although the default settings correspond
to most environments, LoadRunner allows you to modify the settings in
order to customize the scenario behavior. The settings apply to all future
scenario runs and generally only need to be set once.
5-2 LoadRunner Expert Workflow

About Run-time Setting

• Run-time Settings can be configured in VuGen and the Controller.
• Run-time Settings can be configured from three locations.
a) The run time settings button of the Controller for settings associated with the
Vuser groups
b) The Controller Options menu to influence the scenario
c) In the Vuser during script creation
• Different Vuser groups using the same script may use different Run-time settings.
• Script Run-time settings affect Vuser behavior and resource usage “footprints.”
Note: When you modify a script's Run-time settings in the Controller, the new settings are saved
with the Controller scenario. If you open the script in VuGen and modify the Run-time settings,
select the group where the script is running then click Details to open the Group Information
dialog box. Click the Refresh button to see the new settings.
About Run-time Setting 5-3

Vuser Run-time Settings
Script Run-time Settings
Defines settings that affect script execution like run-logic, pacing, logging and think
time.
• Are set in VuGen as well as in the Controller.
• Are used for debugging purposes and to solve playback problems in VuGen.
• Defines how the script behaves when running a load test in the Controller.
5-4 Vuser Run-time Settings

Run-time Settings Vary with Protocol
Figure 5-3 Run-time options change according to the protocol
The Run-time options change depending on the script environment and protocols. For
example, in Web you will see: Browser, Network, and Internet Protocol nodes.
The General settings are common for all protocols.
Run-time Settings Vary with Protocol 5-5

Accessing Run-time Settings
Figure 5-4 Accessing run-time settings
5-6 Accessing Run-time Settings

Run Logic
Figure 5-5 Run Logic tab
Run Logic
• Is used to model more closely the way real users interact with the application.
• Replicates a real user performing steps in a business process more than once.
• Allows setting of the iteration count (how many times a Vuser repeats a task).
• Only the Action portion of the Vuser script will be iterated.
Note: Iterations are only performed in Actions; the Init and End sections are run a single
time.
Run Logic 5-7

Configuring Run Logic - Example
Figure 5-6 Configuring run logic
A real user will log in only once but is sure to perform booking tickets more than once.
The above example indicates that in order to achieve the load testing goal, you will need
to iterate steps 5, 6, and 7 five hundred times - assuming that we have only one Vuser
running the script.
In a real life scenario, this will not be true. If there are ten Vusers running the script, the
number of iteration will be set to 50. If you have 50 Vusers running the script, then the
number of iterations will be 10. This naturally assumes that steps 5,6, and 7 are recorded
inside the “Action” section of the script.
5-8 Configuring Run Logic - Example

Pacing
Figure 5-7 Pacing tab
Pacing
• Controls the delay between iterations.
• Can be used to extend the amount of time a test runs.
Pacing is used to set the pauses between different iterations.
Pacing 5-9
Log Settings
Figure 5-8 Log settings tab
In the Controller, the default logging setting is to send messages only when there is an
error.
Different types of information are logged depending on the options selected.
Logging can provide Vuser information such as:
• Error messages.
• Parameter substitution.
• Transaction status.
• Verification status.
5-10 Log Settings

Log Settings - Best Practices

When sending messages to the output log under large-scale testing, output log size will
greatly affect the scalability of the load generators.
Create two groups of Vusers with different Run-time settings.
• For a majority of Vusers, specify minimal logging.
• For a small sample of Vusers (5%), specify full logging.
Log Settings - Best Practices 5-11

What is Think Time?
Figure 5-9 Think Time tab
Think Time
LoadRunner Think Time is a measurement of the time that a real user takes to pause
between the execution of steps in a business process.
Note: In VuGen, when think time is created, a statement is added to the script. The
statement indicates the amount of time to wait before executing the next step.
• Think Time is waiting between individual steps of a business process
• Pacing is waiting between iterations of business processes
5-12 What is Think Time?

Enabling or Ignoring Think Time

Enabling Think Time
• Introduces the right amount of delay within a business process to emulate user
behavior accurately.
• The best practice is to set Think Time while creating the script (VuGen).
Ignoring Think Time
• Greatly affects the scalability of the load generators.
• May cause the application under test (AUT) to fail with very few Vusers running.
Enabling or Ignoring Think Time 5-13

Configuring Think Time - Example

• Load Testing Goal
– Emulate 500 first-time users buying tickets
• Script
– Script is recorded to emulate an advanced user buying a ticket
Assuming that the average think time for advanced users is 5 seconds and first time
users is 10 seconds, how can you set Think Time to emulate first-time users as required
by the load testing goal?
5-14 Configuring Think Time - Example

Additional Attributes
Figure 5-10 Additional attributes tab
Additional attributes allows you to pass parameters to prepared scripts, enabling the
testing and monitoring of servers with different client parameters.
Additional Attributes 5-15

Miscellaneous Settings
t
Figure 5-11 Miscellaneous settings tab
Error Handling (by default, Error Handling is disabled)
• “Continue on Error” allows Vusers to proceed past an error.
Multithreading
• Threading supports more Vusers per load generator as compared to Process.
• Process supports Vusers that cannot be multithreaded.
Automatic Transactions
• Actions can be automatically “timed” as a Transaction.
• When using Automatic Transactions, script actions should be assigned meaningful

names for clarity.
• Step can also be automatically “timed” as a Transaction.
• When using Automatic Transactions, script steps should be assigned meaningful

names for clarity.
5-16 tMiscellaneous Settings

Additional Settings for Web Vusers

Network
• Configures bandwidth to emulate real-user behavior on the application.
Browser Emulation
• Emulates different browsers to test user experience on response times and content
availability.
Proxy
• Configures Vusers to obtain proxy settings either from the default browser or to
bypass proxy and make direct connections to the Internet.
Preferences
• Generates analysis graphs by selecting options under Generate Web Performance

Graphs.
Additional Settings for Web Vusers 5-17

Additional Settings for Web Vusers - Examples
Figure 5-12 Examples of web vuser settings
5-18 Additional Settings for Web Vusers - Examples

Scenario Run-time Settings - Defined

Scenario Run-time Settings
Allows specifying Vuser quota, stopping behavior, and random sequence seed for
all Vusers and groups for the current scenario.
Scenario Run-time Settings - Defined 5-19

Scenario Run-time Settings
• Vuser Quotas
– Allows setting the number of Vusers to initialize at one time
– Can apply to all or some of the load generators
• Stopping Vusers
– Allows setting how LoadRunner will stop the running of Vusers
• Random Sequence Seed
– Each seed value represents one sequence of random values used for test
execution
– The setting applies to parameterized Vuser scripts and randomized think times
5-20 Scenario Run-time Settings

Summary
• Explained the differences between Script and Vuser Run-time Settings.
• Configured Vuser Run-time Settings based on load testing goals.
• Configured Script Run-time Settings based on load testing goals.
Summary 5-21
Exercise: Introduction to Scenarios

The topics just covered give an introduction to Run-time settings. In this exercise you
will configure Run-time settings in a scenario and then run the scenario.
Exercise A: Configuring Run-time Settings

Part 1: Create a Manual Scenario
1. Invoke the Controller. If the LoadRunner Controller is already open, then move to
step two.
a) From the Windows START menu, select MERCURY LOADRUNNER→

LOADRUNNER. This will launch the LoadRunner main screen / launcher.
2. Create a manual scenario.
If the New Scenario dialog did not appear automatically after you invoked the
Controller or if the Controller is open. Do this:
a) Select FILE → NEW or click the CREATE A NEW SCENARIO button to

open it.
3. Add the BOOKFLIGHT script to the scenario.
a) Select BOOKFLIGHT from the AVAILABLE SCRIPTS list and click the ADD
button. .

\training\loadrunner\Scripts to find it.
c) b) Click OK. The CONTROLLER DESIGN tab opens, displaying the SCENARIO
SCHEDULE and SCENARIO GROUPS panes.

Part 2: Rename Vuser Group and Add Vusers
1. Rename the group to rt_settingsa.
a) Click the DETAILS button. The GROUP INFORMATION dialog opens.
b) In the GROUP INFORMATION dialog box overwrite the text in the GROUP NAME
box with rt_settingsa.
2. Increase the number of Vusers to 10.
a) In the QUANTITY box, overwrite the default number with 10.
b) b) Click OK to close the Group Information dialog.
Part 3: Configure Run-time Settings
1. Open the Run-time Settings.
a) Click the RUN-TIME SETTINGS button . The RUN-TIME

SETTINGS for script dialog will open.
Verify that the Run-time Settings are the same as those in the table below. Change
any setting that does not agree with the table. If there is no row in the table for a
setting, leave it as is.
What option will you use in the Run-time Settings to set iterations?
________________________________________________
NODE SETTINGS
General: Run Enter 6 in Number of Iterations edit box.

Logic

What option will you use in the Run-time Settings to start iterations randomly at
every 30 seconds?
_________________________________________________________
NODE SETTINGS
General: Pacing Check At random intervals, every and enter “30” to and “45” sec.
General: Log Select Enable logging.
Select Extended log.
General: Think Select Replay think time.
Time Check Use random percentage of recorded think time: and enter
“50” in Min and “150” in Max box.
Deselect Limit think time...
2. Save the Run-time Settings.
a) Click OK to save any changes and close the Run-Time Settings dialog
Part 4: Save and Run the Scenario
1. Specify the result file: \training\loadrunner\Results\rt_settingsa.

box opens.
b) Type rt_settingsa in the RESULTS NAME box.

2. Save the scenario .

\training\loadrunner\Scenarios\rt_settingsa.lrs.
3. Run the scenario
a) Click Start Scenario button in the Design tab to run the

scenario.

4. Observe the Scenario Status pane.
a) When the Scenario runs, the tab automatically changes from Design to Run.
b) Observe Scenario Status pane.
How long did the scenario take to run?
__________________________________________________
Part 5: Configure Run-time Settings Again
a) Click the RUN-TIME SETTINGS button . The RUN-TIME

Verify that the Run-time Settings are the same as those in the table below. Change
any setting that does not agree with the table. If there is no row in the table for a
setting, leave it as is.
NODE SETTINGS
General: Pacing Check At random intervals, every and enter “30” to and “45” sec.
General: Log Select Enable logging.
Select Extended log.
General: Think Select Ignore think time.
Time
Part 6: Save and Run the Scenario Again

1. Specify the result file: \training\loadrunner\Results\rt_settingsb.

box opens.
b) Type rt_settingsb in the RESULTS NAME box.

2. Save the scenario .

\training\loadrunner\Scenarios\rt_settingsb.lrs.
3. Run the scenario
a) Click Start Scenario button in the Design tab to run the

scenario.
4. Observe the Scenario Status pane.
a) When the Scenario runs, the tab automatically changes from Design to Run.
b) Observe Scenario Status pane.
How did the scenario behave, when think time were ignored?
__________________________________________________________
Review Questions
1. Where will you set the ‘Vuser Quotas’?
________________________________________________________________
2. What is the difference between ‘Script’ and ‘Scenario’ Run-time Settings?
__________________________________________________________________
_____________________________________________________________

Scenario Execution
Scenario Execution
Objectives
• Prepare for a scenario run
• Identify techniques for running a scenario efficiently.
6-1
Scenario Execution

Scenario Execution
About Running Scenarios

Load Generators at run time:
• Results are stored locally on each load generator.
• After execution, results from all load generators are transferred to the Controller’s
results directory for analysis.
LoadRunner Controller at run time:
• Saves transactions and performance monitor data.
• Synchronizes Vusers via rendezvous function (optional).
• Collects error and notification messages generated by Vusers.
Note: Selecting Run causes the Controller to connect to the Load Generators
automatically. However, you might want to test the connections before trying to run a
scenario.
About Running Scenarios 6-3

Scenario Execution
What is a Rendezvous Point?

Rendezvous Point
An intersection point in a business process.
6-4 What is a Rendezvous Point?

Scenario Execution
Rendezvous
• A Rendezvous is a step added during script creation and defined in VuGen.
• To use a Rendezvous, it must be configured in the Controller.
• When a Rendezvous is present in a script, transaction times become meaningless.
• A Rendezvous policy may be defined in three ways
– Percentage of all users (What if everybody tried to log in now?)
– Percentage of all running Vusers (50% of users arrive between 8AM and 9AM)
– Number of users (What if 10 clients try to log in now?)
When using Rendezvous - why does transaction time become meaningless?
The answer is that when a load test uses a Rendezvous, the system under test is
experiencing high stress as all the Vusers are trying to do task “A” at the same time. This
renders the transaction time meaningless.
Note: Refer to the documentation or VuGen Scripting course to learn more on

Rendezvous points and how to add them to the script.
Rendezvous 6-5
Scenario Execution
Before You Run a Scenario
• Add performance monitors in the Run tab (more information on this is presented in
the performance monitors lesson).
– Adding performance monitors allows you to watch performance in real time.
• Establish Rendezvous policies if necessary.
• Specify a location to save the scenario results and decide on a name for the results.
Select RESULTS → RESULTS SETTINGS to specify a name and location for saving the
scenario results.
6-6 Before You Run a Scenario

Scenario Execution
Executing Scenarios as a Team is

Recommended
Figure 6-2 Executing scenarios is a team process
Running the scenario is straightforward. Execution begins when the Controller's START
SCENARIO button is pressed. But as the virtual users execute their scripts, a whole team
is needed to maximize the usefulness of the test.
• Backend administrators should monitor the performance of each tier of the

application.
• One or more network administrators should monitor the network as load increases.
By using the third-party performance monitoring tools already in place, these
administrators will complement the LoadRunner results and enhance the efficiency
of the root cause analysis process.
Executing Scenarios as a Team is Recommended 6-7

Scenario Execution
Scenario Execution Process: Debug Run
Figure 6-3 Debug run
The Debug run execution
• Shows the responsiveness of the site under low stress.
• Validates that the BP functions for concurrent usage with the data being used in the
test.
• Provides results that can be used as baseline numbers.
The debug run is also a concurrency test. At this point, testing is done to check whether
Vusers can be run concurrently from the Controller.
If your scenario has more than one script, include all those scripts in the Debug run.
6-8 Scenario Execution Process: Debug Run

Scenario Execution
What is a Top Time Transaction?

Top Time Transaction
A LoadRunner transaction that requires significantly longer to complete than other

transactions or takes significantly longer than established goals under relatively small
load.
What is a Top Time Transaction? 6-9

Scenario Execution
Scenario Execution Process: Isolate Top Time

Transactions
Figure 6-4 Isolate top time transactions
The isolate top time transactions run helps us to understand the application’s
responsiveness and allows us to focus on major problem areas.
6-10 Scenario Execution Process: Isolate Top Time Transactions

Scenario Execution
Scenario Execution Process: Full Load
Figure 6-5 Run a full load
Running a successful full load test requires several steps.
1. The entire expected load is applied using a slow ramp up.
2. If the transaction response time degrades, look for bottlenecks.
3. Once a bottleneck is found, backend administrators can modify or enhance the

system to improve performance.
4. Repeat the cycle.
5. Remove subsequent bottlenecks until the system performs well under full load.
6. The results of the first full load test (100%) are used as baseline results to be
compared subsequently with other full load test run results.
Scenario Execution Process: Full Load 6-11

Scenario Execution
Scenario Execution Process: Scalability Test
Figure 6-6 Test scalability
After meeting your load testing goals, the next step is to understand the final limits of
the system. This allows us to do capacity planning for future growth and gives us a
factor of safety with our application. Scalability test is known as Overload/Overdrive
test.
Scalability test allows you to:
• Determine whether your system is scalable for increased load.
• Determine the limit of load that can be handled before more resources are required.
6-12 Scenario Execution Process: Scalability Test

Scenario Execution
Best Practices
• Use results of the first few full load tests (100%) as baselines. Work from them to
measure performance improvement
• If performance does not agree with your goals, use LoadRunner performance
monitors and subject matter experts to isolate bottlenecks. Once a bottleneck is
identified, get experts (backend, application etc.) to fix the problem.
• Understand that testing occurs in cycles and set expectations accordingly. Allow
time between tests for subject matter experts to make changes recommended by test
results.
Best Practices 6-13

Scenario Execution
Vuser Status - Under Controller Run Tab
Figure 6-7
The Vuser status window gives you options to control the Vusers and scenario
execution.
• INITIALIZE and RUN buttons affect selected Vusers
• START SCENARIO runs all Vusers
• VUSERS button opens Vusers window and shows the status of the Vusers
6-14 Vuser Status - Under Controller Run Tab

Scenario Execution
Initializing Vuser Groups
Figure 6-8 Initializing changes vuser status
Initializing Vuser Groups
• Distributes the Vusers in the group to their designated load generators where they
achieve the Ready status needed to start executing their script(s).
• Initializing Vuser groups ensures that the Vusers begin executing the scenario at
approximately the same time.
Initializing Vuser Groups 6-15

Scenario Execution
Understanding Vuser Status
Figure 6-9
The Status field of each group displays the current state of each Vuser in that group.
• Down: The Vusers are down; no activity is going on.
• Pending: When a Run or Start Scenario is invoked, then the scripts are transferred
to the load generator machines, or wait until a load generator becomes available.
• Initialization: The vuser_init section of the script is being run.
• Ready: The Vusers have all finished preparing the load generators and the tasks in
the vuser_init section of the script are now ready for the run. If you have checked
initialization, Vusers that are currently ready will wait for all Vusers to reach Ready
status.
• Running: All the Vusers are running the script on the assigned load generator
machines.
• Rendezvous: (If a rendezvous is defined in the script). The Vusers have arrived at
the rendezvous and are waiting to be released by LoadRunner.
• Passed: If a few Vusers are selected to be run from a scenario group, when they
finish running the script and if they pass, the Vuser status will report a Passed
status.
• Failed: If a few Vusers are selected to be run from a scenario group, if they fail
during the scenario run, the Vuser status will report a Failed status.
• Error: An error occurred. Check the Vuser output window for a detailed
explanation.
6-16 Understanding Vuser Status

Scenario Execution
• Gradual Exiting: The Vusers have completed running the iteration (as specified in
the scenario Run-time settings) and will exit based on Ramp Down options as
specified in the Scenario Builder for a manual scenario. For a goal based scenario,
they will exit based on the scenario settings defined.
• Exiting: The Vusers have finished running the script or have been stopped.
• Stopped: The Stop button is pressed.
Understanding Vuser Status 6-17

Scenario Execution
Vuser Window and Vuser Log
Figure 6-10 Vuser window and log
Vuser Window
• During scenario execution, you can view a log containing run-time

information about each running Vuser.
Vuser Log
• If you disabled the logging feature in the ‘Run-Time Settings’ Log node, the Vuser
script log will be empty.
• If you selected the SEND MESSAGES ONLY WHEN AN ERROR OCCURS option in the
Log tab, the Vuser script log will contain output messages only if there were script
errors.
6-18 Vuser Window and Vuser Log

Scenario Execution
Scenario Status - Controller Run Tab
Figure 6-11 Scenario Status pane
The Scenario Status window provides run time data.
• Number of Vusers currently running
• Elapsed time
• Hits/Second
• Passed/Failed transactions Error count
• Scenario Status (running/down)
Note: Here is one of our first lines of defense. When the AUT starts to fail, it will likely
degrade in transaction time. You may also see failure and error messages.
NOTE THE DIFFERENCE: In the "Scenario Status" in the Run tab view, elapsed
time is calculated from the time the scenario is started. This means that the time is
measured from the time you click on "Start Scenario" or "Initialize/Run Vuser".
However, in the "Vuser" window, elapsed time is calculated from the time the Vuser
enters the 'running' state.
Scenario Status - Controller Run Tab 6-19

Scenario Execution
Scenario Errors
Figure 6-12 Viewing scenario errors
The Output window lists:
• The message code for each type of error.
• A sample message text.
• The total number of messages generated.
• The Vusers and load generators that generated the code.
• The scripts in which the errors occurred.
6-20 Scenario Errors

Scenario Execution
Viewing Scenario Errors - Procedure

1. From the Controller, click the ERRORS entry to open the Output window.
2. To view details of the log information by message, Vuser, script or load generator,
click the link in the respective column.
3. Alternatively, select the message and click the Details button. The Detailed
Message Text box opens in the Output window displaying the complete message
text.
Viewing Scenario Errors - Procedure 6-21

Scenario Execution
Common Run Time Errors

TIMEOUT
• Indicates that the Web server is not responding or that connectivity has slowed
between the load generators and the Web servers.
One or two time-outs may be considered trivial, but a large number of time-outs must be
considered as a serious problem. Confirm with the administrator that the Web server is up
and communicating with the other tiers of the application. Rerun the scenario at a lower
level of load to determine the current performance threshold and help the backend
administrator isolate the problem.
HTTP 500
• Indicates either that individual business processes are failing under load, or that the
Web application itself has crashed.
If your error is identified with a phrase like "HTTP Status-Code=500", a more

serious kind of error has occurred. Do not disregard this problem; either individual
business processes are failing under load, or the Web application itself has crashed.
Identify the step in the script that caused the error, then determine which Web
application components were affected. This is typically done by consulting the
backend application expert.
6-22 Common Run Time Errors

Scenario Execution
Summary
• Specified results directory before running a scenario.
• Followed Best Practices.
– Debugging Run
– Identify any top time transactions
– Full load test
– Scalability test.
• Performance improvement after system adjustment can be confirmed by rerunning

the scenario at the same level of load.
Summary 6-23
Scenario Execution
Exercise: Scenario Execution

The topics just covered explain the stages of scenario execution. In this exercise you will
execute scenarios and view run time data.
Exercise A: Preliminary Runs

1. Continue working with rt_settingsb.lrs.
a) Save a copy of the scenario

as:\training\loadrunner\Scenarios\scenario_ex.lrs.
Number of Vusers for each scenario execution process:
Scenario Number
Execution Process of Vusers
Debug run 2-5

Full load test 20
Scalability 25
Part 1: Running a Few Vusers
1. Rename the group to scenario_ex.
a) Overwrite the text in the GROUP NAME box with scenario_ex.
a) Click the RUN-TIME SETTINGS button .The RUN-TIME

b) Verify that the Run-time Settings are the same as those in the table below.
c) Change any setting that does not agree with the table. If there is no row in the
table for a setting, leave it as is.
NODE SETTINGS
Pacing As soon as the previous iteration ends

Log Extended Log - Parameter substitution and Data returned by server
Think Time Ignore think time
6-24 Exercise: Scenario Execution

Scenario Execution
NODE SETTINGS
General: Check Define each step as a transaction under Automatic

Miscellaneous Transaction.
3. Specify the result file:

\training\loadrunner\Results\scenario_ex_2Vusers.

box opens
b) Type scenario_ex_2Vusers in the RESULTS NAME box.

d) Click OK to close the SET RESULTS DIRECTORY dialog box.
4. Open the VUSERS window.
a) Make sure you are in RUN tab screen.
b) Click the VUSERS button (between the SCENARIO GROUPS and

the SCENARIO STATUS panes) to open the VUSERS dialog box.
5. Run 2 Vusers.
a) Select 2 rows in the VUSERS window and click the RUN button .
b) Wait for the status of each Vuser to change to “Done.” If the Collating Results
dialog is open, close it.
6. If both Vusers finished the run without an error, reset the Vusers to “Down” status.
a) Click the RESET button in the Vusers window. Both Vusers’

statuses should change to Down.
7. Specify the result file again for another run:

\training\loadrunner\scenario_ex__5Vusers.
a) Select RESULTS → RESULTS SETTINGS from the Controller menu.
a) Click the RUN-TIME SETTINGS button .The RUN-TIME

b) Verify that the Run-time Settings are the same as those in the table below.
Exercise: Scenario Execution 6-25

Scenario Execution
c) Change any setting that does not agree with the table. If there is no row in the
NODE SETTINGS

Log Standard log
Think Time Limit think time to 3 seconds
9. Select and Run 5 Vusers from the VUSERS window.
a) Select 5 rows in the VUSERS window and click the RUN button .
Wait for the status of each Vuser to change to “Done.”
Part 2: Examine Vuser Output Logs
1. Open the VUSER OUTPUT windows.
a) Click the Show Vuser Log button in the Vusers window. The Vuser output
windows open.
Click here
2. Check Vuser output for errors.

Scenario Execution
a) a) Click the FIND TEXT button inside the VUSER OUTPUT window dialog
to open the FIND dialog.
b) Type the word “error” in the FIND WHAT box, then click the FIND button.
If the Vuser ran OK, “error” will not be found in the log.
3. Check Vuser output for transaction statuses.
a) Type “transaction” in the FIND WHAT box, then click the FIND button.
All transactions should show a Pass status.
4. Check Vuser output for correct parameter substitution.
a) Type “parameter” in the FIND WHAT box, then click the FIND button.
Parameter substitutions should show different data values for each iteration.
b) Click CLOSE to close the Vuser window.

5. If you see no errors or other problems, close all 5 Vuser output windows (they are stacked
on top of each other) and proceed to the next step. Otherwise, consult the instructor about
how to proceed.
Part 3: Find Top Time Transactions
In the “Find Top Time Transactions” exercise you will be working with the Analysis
part of the LoadRunner tool. Use this part of the exercise to accustom yourself to the
Analysis tool. We will cover more on Analysis in Lesson 8.
1. Open Analysis Summary.
a) Click the RESULTS → ANALYZE RESULTS toolbar button and wait for
the Analysis Summary to appear.
2. Display the Average Transaction Response Time graph.
a) a) Click the AVERAGE TRANSACTION RESPONSE TIME tab.
b) If that tab does not appear in your ANALYSIS window, click the ADD NEW
GRAPH toolbar button to open the OPEN A NEW GRAPH dialog.
c) Expand the TRANSACTIONS category and select AVERAGE TRANSACTION

RESPONSE TIME from the list.
d) Click the OPEN GRAPH button, then close the dialog after the graph appears.

Scenario Execution
Which transaction had the highest average response time? (HINT: Click a line in
the graph to highlight the corresponding row in the grid below.)
___________________________________________________
3. Filter out the BookFlight_Transaction from the graph.
a) Clear the box next to Bookflight_Transaction in the grid.
Why should you remove BookFlight_Transaction from the graph when looking for
top time transactions?
__________________________________________________________________
_____________________________________________
Does the graph show any spikes now? If yes, which transaction(s) caused the spikes?
___________________________________________________
4. Save the Analysis session as:

\training\loadrunner\Results\scenario_ex_5Vusers\res1.
5. Close the LoadRunner Analysis tool.
Exercise B: Load Testing

Part 1: Run Full Load Test
Note: The graphs and questions in this section are intended to be suggestive, not
prescriptive. As you become more familiar with LoadRunner’s analysis tools and with
load testing, you may find other tools and questions useful as well.
Note: During this exercise, you should check the Windows Task Manager
occasionally to make sure that your machine does not run out of resources. If it does,
stop the scenario and scale down the number of Vusers that you run to a number that
does not consume all of the computer’s resources.
1. Select RESULTS → AUTO LOAD ANALYSIS.
TIP LoadRunner can automatically create a results database and display the Analysis
window. If Auto Analysis is not enabled, you can select Results > Analyze Results
from the menu to perform those actions after a scenario has finished running.
2. Specify the result file: \training\loadrunner\Results\scenario_ex_20Vusers.
3. Specify the RUN-TIME SETTINGS.

Scenario Execution
a) In the VUSERS window, click the DETAILS button .The VUSER

INFORMATION dialog opens.
b) Click the RUN-TIME SETTINGS button.
c) Click OK in the Warning message box. The RUN-TIME SETTINGS dialog

opens.
d) Verify that the Run-time Settings are the same as those in the table below.
e) Change any setting that does not agree with the table. If there is no row in the
NODE SETTINGS

Log Disable logging
Think Time Replay think time - as recorded
f) Click OK to close the VUSER INFORMATION window.
4. Reset the Vusers .
5. Select and run 20 Vusers.
a) In the VUSERS window, highlight the first 20 Vusers.
b) Click the RUN button.
c) Wait for the Vusers’ Statuses to change to Done.
6. Save the scenario as: \training\loadrunner\Scenarios\scenario_ex_20Vusers.lrs.
Note: If you were conducting a real load test on your system, you should analyze the test
results at this point and report your findings to the system experts. They should then tune
the system to optimize it for 100% load.
Part 2: Additional Full Load Test
Why would a tester scale the load from 20 to 25 Vusers?
__________________________________

Scenario Execution
1. Specify the result file: \training\loadrunner\Results\scenario_ex_25Vusers.
2. Reset the Vusers .
3. Run 25 Vusers and wait for them to finish.
a) Close the VUSERS window.
b) Click the START SCENARIO button.
c) Wait for the Vusers’ statuses to change to Done.
Note: Make sure you specify the results file for the scenario runs in this exercise. You
will be performing analysis on these results in a future lab.
4. Save the scenario as:

\training\loadrunner\Senarios\scenario_ex_25Vusers.lrs.

Scenario Execution
Review Questions
1. Why is it a good practice to run just a few Vusers the first time?
____________________________
2. Why do the transaction measurements not matter when testing multiple Vusers to
make sure they can run concurrently without errors?
________________________

Scenario Execution

Objectives
• Explain Scheduling by Group and by Scenario
• Configure Duration Scheduling
• Configure Scenario Ramp Up and Ramp Down
• Prepare Vusers for Initialization.
7-1
This section addresses how you can schedule the execution of your scenario.

About Scheduling Scenarios
Figure 7-2 Schedule details
• Enables the repetition of important usage patterns throughout load testing for the
defined duration of the load test.
Using the Schedule Builder, you control the execution of your scenario.
1. Select SCENARIO → SCHEDULE BUILDER or click the Edit Schedule button. The
Schedule Builder dialog box opens.
About Scheduling Scenarios 7-3

Configure Schedule Settings of the Scenario
Figure 7-3 Configuring a schedule
Using the Schedule Builder:
• Select a Schedule name.
– Select the name of the schedule you want to use for the scenario.
– Three default names appear.
• Default Schedule, Ramp Up, and Slow Ramp Up.
• Ramp Up increments the release of the Vusers at a relative pace. Slow

Ramp Up increments the release of the Vusers at a slower pace.
• Create, Rename, and Delete schedule names.
– New: Opens the New Schedule dialog box, enabling you to enter the new
schedule name.
– Rename: Renames the schedule.
– Delete: Deletes the schedule name.
7-4 Configure Schedule Settings of the Scenario

Configure Scenario Start Time
Figure 7-4 Scenario Start dialog box
Scenario Start Time
• Enables you to start running a manual or goal-oriented scenario at a later point in

time.
• Specifies 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.
2. Specify how long to delay after the Run command is issued, or specify a particular
date and / or time.
Configure Scenario Start Time 7-5

Schedule by Scenario
Figure 7-5 Schedule by scenario
Scheduling by Scenario
• Applies the same schedule across all groups.
• Creates a profile of usage by “users.”
• Allows you to control the execution of the scenario.
– Gradually running Vusers within a scenario
– Limiting the scenario duration
– Gradually stopping Vusers within a scenario.
7-6 Schedule by Scenario

Schedule by Group
Figure 7-6
Scheduling by Group
• Applies individual settings for each group.
• Allows you to delay the start time for Vuser groups and the scenario.
• Create a profile of usage by “Business process.”
• Allows you to control the execution of the groups by:
– 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.
Schedule by Group 7-7

Ramp Up
Figure 7-7 Ramp up settings
Ramp Up
• Allows loading all Vusers in the scenario gradually.
• Timed increments pinpoint the exact point at which a system/software fails or

degrades.
• Best Practices
– A moderate or slow ramp-up is recommended when gauging the maximum

number of users a system can accommodate.
– Transaction response time goals are most quickly met with immediate load.
– When the application has reached a threshold, heavy ramping down will allow
you to detect any memory leak or check network latency or database integrity.
7-8 Ramp Up
Ramp Down
Figure 7-8 Ramp down settings
Ramp Down
• Only applicable for scenarios where the Duration tab "Run for" option is selected.
• Specify how many Vusers to stop and how often.
• Stop all Vusers at once.
• Can be used to detect memory leak and system recovery after heavy load.
• Best Practices
– When the application has reached a threshold, heavy ramping down will allow
you to detect any memory leak or check network latency or database integrity.
Ramp Down 7-9

Scenario Duration
Figure 7-9
The Duration tab allows you to select how long your scenario runs.
Run until completion
• Runs for the specified number of iterations.
Run for
• Runs the scenario for the specified duration time.
Run indefinitely
• Runs the scenario indefinitely for testing the stability of the application (volume
testing).
7-10 Scenario Duration

Scenario Duration - Best Practices

Run until completion
• Use this option when you have unique values in your script. For example, the script
creates unique records for the application, and you want to create only 1000
records. Choose Run until completion to guarantee that only the specified number
of iterations are run.
Run for
• Run the ‘Actions’ part of the script for the specified duration. Use this option when
there are no unique values in the script.
Run indefinitely
• Runs the ‘Action’ part of the script indefinitely. You have to stop the scenario
manually. Use this option when you do not have any unique
values in the script and for stability testing.
If the Run for option is selected and the Initialize all Vusers before run is not checked,
then consider that some Vusers may take a longer time to initialize and may never reach
the Running state before the scenario ends.
Calculate the total time required for initializing all the Vusers. The Run for option
should be set to a higher number than the calculated time. This will ensure that all the
Vusers in the scenario will reach the Run status before the scenario ends.
Note: The duration setting under the Run for option overrides the Vuser iteration
settings. This means that if the duration is set to five minutes, the Vusers will continue to
run as many iterations as required in five minutes even if the run-time settings specify
only one iteration.
Scenario Duration - Best Practices 7-11

Initialization
Figure 7-10
You can initialize all Vusers before the run.
Initialization prepares the Vusers and the load generator machines for a load test run.
During initialization, the vuser_init section of the script is executed. For some protocols,
this section includes information for initializing pointers or handles. However, most of
the protocols contain nothing in the vuser_init section except the business process steps
you have recorded.
• Why is initialization important?
– Initializing all Vusers before ramp-up reduces CPU consumption and get
realistic results. Web Vusers initially cause a huge impact as compared to SAP
Vusers, causing the memory utilization to be ten times greater.
– Initializing Vusers before ramp up ensures that all the Vusers are ready to start
running the scenario. If initialization is not checked before running the
scenario, some Vusers will take longer to reach the ready status while others
might be already running the scenario.
7-12 Initialization
What Happens When the Stop Button is

Pressed?
Figure 7-11
1. The Controller stops the Vusers according to the settings defined in the Scenario
Run-time Settings tab.
2. If you have set the option to stop Vusers running when the Stop button is clicked,
the Vusers will stop immediately.
3. If you instructed a Vuser to complete the iteration it is running before stopping, then
Vusers will continue to run even after the stop button has been pressed.
4. Once the current iteration is completed the Vusers will stop running.
In other words, if you have defined Vusers to complete the action they are running
before stopping, then Vusers will complete the run.
What Happens When the Stop Button is Pressed? 7-13

Summary
• Explained the elements of Scheduling a Scenario by Scenario and Group.
• Initialize Vusers before ramp up if appropriate for your load testing goal.
7-14 Summary
Exercise: Scheduling Scenarios

The topics just covered explained the need to properly schedule a scenario. In this
exercise you will schedule a scenario based on specific load testing needs.
Exercise A: Scheduling a Scenario based on load testing needs

For this exercise, use the existing script available at
c:\training\loadrunner\Scripts\BookFlight.
Load testing needs
1. An application on the west coast has a customer base concentrated in Asia working
from midnight to 2 a.m. During this time, a batch process is also run. How can the
overall system performance for this time period be tested at midnight without the
physical presence of a tester?
__________________________________________________________________
_______________________________________________
Utilize the LR Controller and schedule the scenario to achieve the objective in question
one. Try to do so without looking at the steps listed below. Use them only when you find
yourself unable to proceed without detailed instructions.
Steps to schedule a manual scenario

1. Invoke the Controller.
a) From the Windows Start menu, select MERCURY LOADRUNNER →

LOADRUNNER. This will open the LoadRunner main screen / launcher.
b) Under the Load Testing tab, click the RUN LOAD TESTS link. This will open
If the LoadRunner Controller is already open, then move to step two.
2. Create a New Manual Scenario.
a) If the NEW SCENARIO dialog did not appear automatically after you invoked
the Controller, select FILE → NEW or click the CREATE A NEW SCENARIO
button to open it.
Exercise: Scheduling Scenarios 7-15

3. Add the BOOKFLIGHT Script to the Scenario.
a) a) Select “BOOKFLIGHT” from the AVAILABLE SCRIPTS list and click the ADD
BUTTON.

c:\training\loadrunner\Scripts to find it.
c) Click OK. The CONTROLLER DESIGN tab opens, displaying the SCENARIO
SCHEDULE and SCENARIO GROUPS panes.
4. Schedule the Scenario.
a) Click EDIT SCHEDULE button under the SCENARIO

SCHEDULE pane. The SCHEDULE BUILDER window opens, displaying the
scheduling options.
b) Click the SCENARIO START TIME button . This will open

the SCENARIO START window.
c) Select AT option and specify to start the scenario at midnight and the date.
d) Click OK to close the Scenario Start window.
Specify the time and date to

start running the scenario.
e) Click the DURATION tab and select RUN FOR option. Set it to run for two
hours. This will run the scenario from 12 in the midnight to 2 am.
f) Once you are done scheduling the scenario, Click OK to close the SCENARIO
BUILDER window.
5. Save the Scenario as:

c:\training\loadrunner\Scenarios\sched_scenario_a.lrs
7-16 Exercise: Scheduling Scenarios

Exercise B: Schedule Another Scenario

1. Open rt_settingsb.lrs and save a copy of the scenario as:
c:\training\loadrunner\Scenarios\sched_scenario_b.lrs
Part 1: Add Vuser Group
1. Create a new group named group2 and add 10 Vusers. Leave the pre-existing
group as is.
a) Click ADD GROUP button to open the ADD GROUP dialog.
b) In the GROUP NAME box, type group2
c) In the LOAD GENERATOR NAME box, make sure localhost is selected.
d) In the VUSER QUANTITY box, make sure 10 is selected.
e) Click OK to close the ADD GROUP dialog.
Part 2: Schedule the Vuser Groups in the sched_scanario_b Scenario
1. Open the SCHEDULE BUILDER.
a) Click EDIT SCHEDULE button . The SCHEDULE BUILDER

window opens displaying the scheduling options.
b) Select the SCENARIO START TIME button. This will open the SCENARIO START
window.
What option will you use to schedule the group2?
___________________________
2. Set scheduling by Vuser group
a) Select SCHEDULE BY GROUP radio button under SCHEDULE BY DEFINITION

pane.
Where will you set the start time for group2?
___________________________
3. Schedule group2 to start two minute after scenario begins.
a) Select “group2” group.

b) Select START TIME tab.
c) Select “START” option and specify 02 for minutes in the “AFTER THE
SCENARIO BEGINS” edit box.
4. Schedule group2 to ramp up two Vusers every minute.
a) Select RAMP UP tab.
b) Select “START” option and specify 2 in the “VUSERS” edit box.
c) Specify 01 for minutes in the “(HH:MM:SS)” edit box.

5. Schedule group2 to run for thirty minutes.
a) Select DURATION tab.
b) Select “RUN FOR” option and specify 30 for minutes in the “(HH:MM:SS)”
edit box.
6. Schedule group2 to ramp down two Vusers every minute.
a) Select RAMP DOWN tab.
b) Select “STOP” option and specify 2 in the “VUSERS” edit box.
c) Specify 01 for minutes in the “(HH:MM:SS)” edit box.

7. Schedule rt_settingsa to start one minute after scenario begins.
a) Select the “RT_SETTINGSA” group.
b) Select START TIME tab.
c) Select “START” option and specify 01 for minutes in the “AFTER THE
SCENARIO BEGINS” edit box.
8. Leave default settings in the ramp up, duration and ramp down tabs.
a) Do not change any other settings in the following tabs: Ramp Up, Duration,
and Ramp Down.
9. Initialize the Vusers before run.
a) Check “INITIALIZE ALL VUSERS BEFORE RUN” box.
b) Click OK to close the Schedule Builder.
Scenario Groups pane will show you the different scheduling settings for the
groups.
Part 3: Save and Run the Scenario
1. 1. Save the scenario.

\training\loadrunner\Scenarios\sched_scenario_b.lrs.
2. Specify the result file: \training\loadrunner\Results\sched_scenario_b.
a) Select RESULTS → RESULTS SETTINGS. The Set Results Directory dialog box
opens.
b) Type sched_scenario_b in the RESULTS NAME box.


d) Click OK to close the SET RESULTS DIRECTORY dialog box.
a) Click Start Scenario button to run the scenario .
4. 4. Observe the Vusers’ statuses and then answer the questions below.
a) Make sure that you are in Run tab.
b) Watch the Scenario Groups pane to observe what statuses Vusers go through.
Which group ran first and why?
__________________________________
Did Vusers from both the groups get initialized before moving to the “Run” state?
__________________________________________________________________
__
How long did it take for the groups to start running the scenario after the
Start Scenario button was pressed?
_______________________________________
Based on your observation of the scenario run, explain the Vuser status behavior
between the two groups.
_______________________________________
Review Questions
Review Questions
1. Explain the difference between using Schedule By Scenario and Schedule By

Group.
_______________________________________________________
2. Explain what happens when ‘Initialize all Vusers Before Run’ is checked.
_________________________________________________________________


Objectives
• Explain the value of performance monitors
• Select performance monitors to achieve load test goals
• Add measurements for performance based on goals.
8-1

Transactions Are Not the Whole Story
Figure 8-2 Transaction information tells part of the story
• Transactions measure the time required by a business process
• Most load testing goals are measured against their performance
• One transaction usually relies on a different set of components and tiers than
another, so the relative performances of various transactions suggest a picture of
those components' performance.
For example, the Search transaction took 30 seconds. This result is considered to be poor
performance.
We know that the process took too long, but we have no way of telling where the
bottleneck occurred. It could have been the Application server, the Network, the Web
server, or the DNS resolution.
Therefore, we must conclude that transaction timings alone are not conclusive enough to
pinpoint a bottleneck.
Transactions Are Not the Whole Story 8-3

The Value of Performance Monitors
Figure 8-3 Performance monitors complete your information
Apart from transactions performance, you need performance monitors to highlight

system component bottlenecks.
Performance monitors may detect such things as:
• Web server memory usage is at the maximum
• Low activity is registered by the database server
• Underutilization of the application server
8-4 The Value of Performance Monitors

Using Performance Monitors

• LoadRunner offers a wide range of performance monitors for isolating bottlenecks
– Monitors are non-intrusive and agentless
– Monitors gather data for online/offline analysis
– Monitors display real-time data during testing
– Monitors gather data for offline root cause analysis after testing
Performance monitors report performance metrics for a variety of major backend system
components, including firewalls and Web, application, and database servers. Monitoring
these during scenario execution can immediately pinpoint the source of poor
performance. This monitoring may be conducted within the firewall of the application
under test, or behind a remote firewall with the load generators.
In addition to server software monitors described, any NT or UNIX component can also
be monitored at the OS level. This will indicate processor, disk, and memory utilization
and stress. Problems in these areas often suggests a root cause poor performance. For
example, maxed out memory in a Web server suggests that a memory upgrade may
improve performance. Very low activity suggests that a component is not being utilized.
Problems may be found 'upstream.' For example, a database server may show little
activity because of an application server failure.
Using Performance Monitors 8-5

Examples of LoadRunner Performance Monitors
Figure 8-4 LoadRunner performance monitors
• LoadRunner uses a suite of integrated performance monitors to quickly isolate

system bottlenecks with minimal impact to the system
• The suite consists of a large variety of monitors as listed in the graphic
These monitors are designed to accurately measure the performance of every single tier,
server, and component during the load test. Each type of server monitor has a different
set of metrics. For instance, Web server monitors provide performance data such as
active connections, hits per second, etc. System resource monitors measure CPU usage,
cache hits, page faults, etc.
Note: Apache, Netscape, and IIS performance monitors are included with LoadRunner.
All additional monitors require a seperate license.
8-6 Examples of LoadRunner Performance Monitors

Online
Monitors
Figure 8-5 Online performance monitors
Performance monitors:
• View and collect statistics during scenario execution using LoadRunner Controller
online graphs
• Correlate the collected statistical data in LoadRunner Analysis after scenario

execution for root cause analysis
• Facilitate collaboration between project members during and after Scenario

execution by allowing users to view multiple performance monitors via the browser
• Selecting which performance monitors to add should be part of test planning
Note: You can display up to 16 online monitors at a time.
Performance Monitors 8-7

Selecting Online Monitors - Procedure

1. Drag item from list to a graph window (or double-click item to put in current
window).
2. Double-click a graph window to enlarge it.
8-8 Selecting Online Monitors - Procedure

License Information
• Performance monitors are licensed by the LoadRunner Controller
• A monitor cannot be configured unless the license has been purchased
To find out which monitors your current license allows:
1. Click the License button on the LoadRunner launcher screen.
Figure 8-6 License information
License Information 8-9

Set Monitoring Options
Figure 8-7 Options dialog box
The OPTIONS dialog box
– Enables the Transaction monitor
– Configures the behavior of the transaction data
– Sets the data sampling rate, error handling, debugging, and frequency settings
for the online monitors.
It is recommended that the frequency of small scenarios be set at 1 and larger scenarios
at 15. The higher the frequency, the less network traffic there will be.
Note: The load generator must be in down status for the frequency to be configurable.
8-10 Set Monitoring Options

Set Monitoring Options - Procedure

To set monitoring options:
1. Select TOOLS → OPTIONS. The OPTIONS dialog box opens.
2. From the monitors tab, enable ENABLE TRANSACTION MONITOR. This specifies the
frequency at which the monitor sends updates to the Controller
3. Enable SEND ERRORS TO THE OUTPUT WINDOW (recommended).
Set Monitoring Options - Procedure 8-11

Configure Monitors
Figure 8-8 Adding monitor measurements
To add measurements for a System Resource monitor:
1. Right-click a monitor pane
2. Select ADD MEASUREMENTS from the pop-up menu
3. Select server machine name and resources to monitor from the dialog
Note: Most monitors require administrative/root privileges. Refer to Mercury

knowledge base article 19173 to enable non-admin users to remotely monitor with
PERFMON.
8-12 Configure Monitors

Configure Monitors Procedure

1. Right-click a monitor pane.
2. Select ADD MEASUREMENTS from the pop-up menu.
3. Click ADD. The Add Machine dialog box opens.
4. Add the load generator’s name and select a platform. Click OK.
This will list all the available measurements for the chosen monitor.
Configure Monitors Procedure 8-13

Monitor Measurements
Figure 8-9 Monitor measurements
Many system-level resources can be measured.
• By default, LoadRunner selects many of the important measurements.
• Consult with subject matter experts to determine if additional measurements should

be monitored.
Note: For each monitor, numerous measurements are available.
8-14 Monitor Measurements

Best Practices for Choosing Monitor

Measurements
For an initial load test, add all default measurements.
• Provides a broad spectrum view of system behavior.
• Assists in isolating potential bottlenecks.
For follow-up load tests, add specific measurements after speaking to the subject matter
experts.
• Targets a suspected server.
• Permits backend experts to confirm their diagnosis.
Best Practices for Choosing Monitor Measurements 8-15

Summary
• Transaction time alone is not enough to isolate performance problems. We need to
know where the time was spent.
• Understood what monitors and measurements to select based on the load testing
goals.
• Added monitors and measurements to achieve goals.
8-16 Summary
Exercise: Performance Monitors

The topics just covered gave you some insight into performance monitors. In this
exercise you will add and configure a performance monitor.
Exercise: Add and Configure Monitors

1. Continue working with rt_settingsb.lrs.
a) Save a copy of the scenario as: \LR81_project\Scenarios\perf_monitor.lrs
Part 1: Rename the Group
1. Rename the group to perf_monitor
a) Overwrite the text in the GROUP NAME box with perf_monitor.
Part 2: Add Throughput Web Resources Monitor and Measurements
1. 1. Check status of Load Generator.
a) Click on the GENERATORS button . This opens the LOAD

GENERATORS dialog.
b) Check the status of the load generator.
Make sure that the load generator machine’s status shows “Down”.
c) If not, then select the LOAD GENERATOR and click the DISCONNECT button to
change the status from "Ready" to "Down".
2. Display 4 monitor graph panes in the Run tab.
a) Click the Run tab at the bottom of the Controller’s main window.
b) If only 2 graph panes are visible, select VIEW → VIEW GRAPHS → SHOW
FOUR GRAPHS.
3. 3. Set monitoring options.
a) Select TOOLS → OPTIONS to open the OPTIONS dialog box.
b) Click the MONITORS tab and check ENABLE TRANSACTION MONITOR and
select 15 in the FREQUENCY edit box.
c) Click OK to close the Options dialog box.
Exercise: Performance Monitors 8-17

What is the benefit of checking ENABLE TRANSACTION MONITOR?
__________________________________________________________________
4. Connect to the Load Generator.
a) Go the DESIGN tab.
b) Select the machine that you added as a Load Generator machine, and click the
GENERATORS button.
c) Once you are in a Load Generators window click CONNECT. Make sure that
the load generator status changes to “Ready,” then click CLOSE.
5. Add the Throughput Web Resources monitor.
a) Go to the RUN tab in the Available Graphs list.
b) Click the “+” next to Web Resource Graphs to expand the graph tree (if it
already shows "-", ignore this step).
c) Select “THROUGHPUT” and drag it over HITS PER SECOND - WHOLE SCENARIO
GRAPH.
Note: You will now see that the HITS PER SECOND GRAPH is replaced with THROUGHPUT
graph.
6. Add the default measurements for the Windows Resources monitor.
a) If the WINDOWS RESOURCES MONITOR is not already visible in one of the

graph panes, expand SYSTEM RESOURCE GRAPHS, select WINDOWS
RESOURCES, and drag it to one of the graph panes.
b) Right-click the WINDOWS RESOURCES graph pane and select “ADD

MEASUREMENT(S)” from the pop-up menu. The WINDOWS RESOURCES dialog
opens.
c) Click the ADD button in the MONITORED SERVER MACHINES pane. The ADD
MACHINE dialog opens.
d) Type your machine’s name in the NAME edit box.
e) Choose the correct version of Windows from the PLATFORM list, then click OK
to close the ADD MACHINE dialog.
f) In the RESOURCE MEASUREMENTS ON: pane the default measurements

available for this monitor are displayed.
8-18 Exercise: Performance Monitors

g) Click OK to close the WINDOWS RESOURCES dialog and start the monitor.
7. Familiarize yourself with the monitor information.
a) Double-click the Windows Resources graph pane to enlarge it.
Notice that each measurement appears on a color-coded row in the bottom pane
of Controller’s main window. Each row corresponds to a line in the graph of
the same color.
b) Select a row to highlight the corresponding line in the graph.
Who would you consult for advice on which Windows counters to set?
__________________________________________________________________
__________________________________________________________________
What is the benefit of the Windows Resources Monitor?
__________________________________________________________________
__________________________________________________________________
_
Part 3: Add Apache Web Server Resource Monitor and Measurements
1. Add the Apache Web Server Resource monitor.
a) Double-click the WINDOWS RESOURCES graph to reduce it and to bring the

other graph panes back into view.
b) Select “APACHE” from the WEB SERVER RESOURCE GRAPHS, drag it into the
graph view area, and drop it on top of the TRANSACTION RESPONSE TIME
graph.
2. Add measurements to the Apache Monitor.
a) Right-click the Apache graph pane and select "ADD MEASUREMENT(S)" from
the pop-up menu. The Apache dialog opens.
b) Click the ADD button in the MONITORED SERVER MACHINES frame.
c) Type your machine’s name in the NAME box in the ADD MACHINE dialog. (If
the Apache Web Server is running on a different machine, use that machine’s
name instead.)
d) Choose the correct version of Windows from the PLATFORM list.
e) Click OK to close the ADD MACHINE dialog.

f) Click the ADD button in the RESOURCE MEASUREMENTS ON: pane. The
APACHE - ADD MEASUREMENTS dialog opens.
g) Type /server-status? auto in the URL box if it’s not already there.
h) Select the first item in the list, then hold down the Shift key and click the last
item. The entire list should now be selected. Click OK to add all items.
i) Click OK to close the Apache dialog and start the monitor.
After several seconds you should begin to see lines appear on the Apache graph. If you
do not, there may be a problem with your httpd.conf file.
3. Confirm that Apache server is running.
a) Bring up http://localhost/server-status? auto on your browser.
If you can see data here but no lines in your Apache graph in the Controller
then repeat step 2 and instead of using the machine name, use localhost.
Note: If data does not appear on your Apache monitor graph,
1. Run the Stop Server program in the Mercury Tours program group.
2. In Notepad, open the file:

\MercuryTours\Apache Group\Apache\Conf\httpd.conf
3. Find the following line:

#LoadModule status_module modules mod_status.so
4. Delete the “#” character.
5. Delete # from the line: #ExtendedStatus On
6. Also delete the “#” character from these lines:
#<Location /server-status>
#SetHandler server-status
#</Location> [the first line where this occurs after SetHandler server-status]
7. Save the changes and close Notepad.
8. Restart the Apache server.
4. In the graph view area you should see Running Vusers, Apache, Throughput, and
Windows Resources monitors.

5. Resave the scenario as: \LR81_project\Scenarios\perf_monitor.lrs
Review Questions
1. Explain the best practices for selecting monitor measurements.
__________________________________________________________________
________________________________________________________________
2. Explain the value of performance monitors.
__________________________________________________________________
________________________________________________________________


Results Analysis
Results Analysis
Objectives
• Explain the value of results analysis
• Diagnose errors using LoadRunner
• Interpret LoadRunner graphs to derive meaningful results by drilling down to root

cause problems.
9-1
Results Analysis
Where did the Failure Occur?
Figure 9-1 Where did the system failure occur?
Any link in the chain between the browser and the database could be the cause of an
application failure or performance degradation.
LoadRunner Analysis provides multiple perspectives on site performance that help

identify bottlenecks.
9-2 Where did the Failure Occur?

Results Analysis
Root Cause Analysis
Figure 9-2 Root cause analysis process
Performing root cause analysis means drilling down from the most general reports to
localized metrics
The combination of complex applications and the dynamic characteristics of network

traffic can cause significant degradation in application performance. Performance
problems can occur at many points along the route between the application and users.
These problems may be caused by a variety of events. Performing analysis using
LoadRunner tools helps you to find bottlenecks and thus improve the performance of
your application.
How are bottlenecks pinpointed during results analysis? There are typically three
phases:
• 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.
Root Cause Analysis 9-3

Results Analysis
Did You Meet Your Goals
Figure 9-3 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.
9-4 Did You Meet Your Goals

Results Analysis
Results Analysis - Setting the Stage

The following hypothetical situation is the basis of this chapter’s discussion:
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.
Results Analysis - Setting the Stage 9-5

Results Analysis
Average Transaction Response Time
Figure 9-4 Average response time graph
• Details transaction response throughout the test.
• 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?
9-6 Average Transaction Response Time

Results Analysis
Average Transaction Response Time Under

Load
Figure 9-5 Average transaction response time under load graph
• 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?
Average Transaction Response Time Under Load 9-7

Results Analysis
Transaction Response Time Percentile
Figure 9-6 Transaction response time percentile graph
• 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?
9-8 Transaction Response Time Percentile

Results Analysis
Transaction Response Time Distribution
Figure 9-7 Transaction response time distribution graph
• 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.
Transaction Response Time Distribution 9-9

Results Analysis
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.
LoadRunner Analysis provides:
• Filtering to hide unwanted data from analysis.
• Regrouping to assemble data as desired by merging graphs, tiling, and auto-

correlation.
• 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.
Note: To get more info on this go to books onlines and click on LoadRunner Analysis
User’s Guide book.
9-10 Working with the Data

Results Analysis
Opening a New Graph
Figure 9-8 Opening a new graph
1. Click the “+” <New Graph> icon on the toolbar menu. The Open a New Graph
window opens.
2. Select the graph that you need.
3. Click the Open Graph button to open the graph.
Only graphs which contain data are selectable.
Opening a New Graph 9-11

Results Analysis
Drilling Down
Figure 9-9 Drill Down Options dialog box
1. Right-click on the graph.
2. Select DRILL DOWN to open the dialog box.
3. Select a Transaction.
4. Select a GROUP BY field.
5. Drill down again to find out which Vusers failed.
Drill-Down Options: Let’s focus on a specific measurement within your graph. You
select one measurement within the graph and display it according to desired grouping.
For example, the Average Transaction Response Time graph shows one line per
transaction by default. To determine the response time for each host, drill down on one
transaction and sort it according to host. The graph displays a separate line for the
transaction response time on each host.
9-12 Drilling Down

Results Analysis
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.
Setting Filters 9-13

Results Analysis
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 available.
9-14 Analysis Session File Extensions

Results Analysis
Isolating the Network
Figure 9-10 Isolating the 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.
Isolating the Network 9-15

Results Analysis
Isolating the Network - Graph Analysis

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”.
9-16 Isolating the Network - Graph Analysis

Results Analysis
Isolating Network Issues
Figure 9-11 Isolating network issues
• 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.
Isolating Network Issues 9-17

Results Analysis
Isolating Server Issues
Figure 9-12 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.
9-18 Isolating Server Issues

Results Analysis
Isolating Server Issues
Figure 9-13 Isolating server issues - continued
• 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.)
Isolating Server Issues 9-19

Results Analysis
Interpreting Graphs
When you see a measurement in the graph flatten out, it means that the hardware or
software has reached it’s 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 LoadRunner 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.
9-20 Interpreting Graphs

Results Analysis
Time to First Buffer Breakdown
Figure 9-14 Time to First Buffer Breakdown graph
• 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.
Time to First Buffer Breakdown 9-21

Results Analysis
Page Download Time Breakdown
Figure 9-15 Page Download Time Breakdown graph
• Identifies Web pages that take the most time and isolates where time is spent.
• Helps isolate DNS resolution issues, SSL issues, and connection issues.
After we identify server vs. network, we need to drill down to the specific metric that is
causing an issue. LoadRunner dissects these transactions into the different components
of a request. Any connection issues, SSL issues, DNS issues, or FTP issues will show up
in the Page Download Time Breakdown graph.
Again, our graph is pointing to the Time to First Buffer metric.
9-22 Page Download Time Breakdown

Results Analysis
Use Auto Correlation Feature to Pinpoint

Bottlenecks
Auto Correlation
• Allows automatic selection of graphs to correlate in order to find the metrics that
most influence the transaction response time
• Automatically correlates the transaction graph with all performance metrics and
displays the ones that show the highest match in their behavior; this allows you to
disregard irrelevant metrics
• Visually displays correlated metrics closely correlated to the transaction response

time, which speeds identification of the likely causes of performance bottlenecks
Auto Correlation lets you correlate a measurement in a graph with other monitor
measurements during a specific time range of the scenario. This enables you to view
similar measurement trends.
The Auto Correlation feature applies sophisticated statistical algorithms to

pinpoint the measurements that had the greatest impact on a transaction’s response time.
Correlating the response time with each metric and identifying the metrics that are most
likely correlated poor response time can takes a lot of time. This is due to the number of
metrics each graph displays. Auto Correlation allows you to do this without any trouble
and in less time.
Use Auto Correlation Feature to Pinpoint Bottlenecks 9-23

Results Analysis
Auto Correlate - Time Range
Figure 9-16 Selecting a time range
1. 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.
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.
2. 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.
3. Click BEST for the segment of the graph most dissimilar to its adjacent segments.
4. 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.
9-24 Auto Correlate - Time Range

Results Analysis
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.
5. 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.
Auto Correlate - Time Range 9-25

Results Analysis
Auto Correlate - Correlation Options
Figure 9-17 Selecting 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.
9-26 Auto Correlate - Correlation Options

Results Analysis
– 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.
Auto Correlate - Correlation Options 9-27

Results Analysis
Displaying Analysis Reports

• HTML Format
– Ease of sharing analysis results with other remote team members.
• Word Format
– Can add comments and format the analysis data based on your needs.
HTML Reports - The Analysis tool lets you create HTML reports for your
scenario run. It creates a separate report for each open graph and a Summary report. This
Summary report is identical to the Summary report that you access from the Analysis
window. This report also provides a link to an Excel file
containing the graph data. Refer to the LoadRunner documentation on how to create
HTML reports.
9-28 Displaying Analysis Reports

Results Analysis
Displaying Analysis Reports - Procedure

To creating HTML reports: (Instructor will demo)
1. Open all graphs that you want to include in the report.
2. Choose REPORTS → HTML REPORT or click the CREATE HTML REPORT

button. The SELECT REPORT FILE NAME AND PATH dialog box opens.
3. 3. Specify a path and file name for the HTML report and click OK.
The Analysis saves a Summary report called by the file name in the selected folder,
and the rest of the graphs in a folder with the same name as the file name. When you
create an HTML report, the Analysis opens your default browser and displays the
Summary report.
Word Reports - The Analysis tool provides a simple interface that allows you to create
an Analysis report in MS Word format.
Creating the Word reports: (Instructor will demo this)
1. Launch the Import Data Tool by selecting REPORTS → MICROSOFT WORD

REPORT from the main menu of LoadRunner Analysis.
2. Set the options you require in the FORMAT tab and press OK.
The report is then generated, and a window appears to reporting its progress. When
the report is completed, Analysis launches the Microsoft Word application to
display the report. The file is saved to the location specified in the Report Location
box of the Format tab.
FORMAT OPTIONS allow you to add custom information to the Word report, as well
as to include additional pages and descriptive comments. To learn more on creating
Word reports, refer to the LoadRunner documentation.
Displaying Analysis Reports - Procedure 9-29

Results Analysis
Summary
• Monitor all components in your application to generate data graphs
• Correlated LoadRunner graphs with monitor measurements to isolate root cause
• Associated LoadRunner results with load testing goals to improve end-user

experience
9-30 Summary
Results Analysis
Exercise: Results Analysis

The topics just covered gave you some insight into identifying system problems using
the LoadRunner Analysis. In this exercise you will analyze results from an actual
scenario
Exercise A: Analyze Results of Previous Scenario Runs

Part 1: Analyze Results from Scenario Execution Labs
1. Launch the LoadRunner Analysis program.
a) If the LoadRunner program is open, click the ANALYZE LOAD TESTS link
from the Load testing tab. This launches the Analysis program.
b) If the LoadRunner program is not open, select MERCURY LOADRUNNER →

LOADRUNNER from the Start menu. This will launch the LoadRunner program.
2. Open the results file:

3. Check the Transaction Summary.
a) When LoadRunner finishes processing the results data, it displays the Analysis
Summary. Look at the Transaction Summary.
How many passed and failed transactions does the Transaction Summary show?
What percentage of all transactions failed?
__________________________________________________________________
________________________________________________
4. Open the Apache graph (from the Web Server Resources category).
a) a) Select GRAPH → ADD GRAPH or click <NEW GRAPH> in the graph

tree view. A New Graph dialog box opens.
b) Click "+" to expand the graph tree and the WEB SERVER RESOURCES graph.
c) Select the APACHE graph.
5. Compare Busy Servers and Idle Servers in the Apache graph.
a) Hold down the Shift key, then, in the grid below the Apache graph, click the #BUSY
SERVERS (APACHE) and #IDLE SERVERS (APACHE) rows.
What do you notice about the Busy and Idle Servers lines in the Apache graph?
Exercise: Results Analysis 9-31

Results Analysis
__________________________________________________________________
________________________________________
6. Display the AVERAGE TRANSACTION RESPONSE TIME graph.
7. Filter out the BOOKFLIGHT_TRANSACTION transaction.
a) In the grid below the graph, uncheck BookFlight_Transaction.
What do you notice about the graph now?
__________________________________________________________________
________________________________
What would you guess caused the purchase_flight transaction to peak higher than
any other transaction?
__________________________________________________________________
________________________________________________________________
8. Save the session and close the Analysis window when you are finished.
a) Save the session as:

\training\loadrunner\Results\res_analysis_20Vusers\res1.
Note: If you were conducting a real load test on your system, at this point you would
analyze the test results and report your findings to the system experts. They should then
tune the system to optimize it for 100% load.
Part 2: Compare Full Load and Overload Run Results
1. Open the results file:

2. Create cross result graphs.
a) In the Analysis window, select FILE → CROSS WITH RESULT. The CROSS
RESULT dialog opens with scenario_ex_25Vusers.lrr already in the list.
b) Click the ADD button. The Open Result File for New Analysis Session dialog
opens.
c) Navigate to \training\loadrunner\Results\scenario_ex_20Vusers,
select the file scenario_ex_20Vusers.lrr, and click OPEN.
d) Click OK to close the CROSS RESULT dialog. LoadRunner creates a new

database.
9-32 Exercise: Results Analysis

Results Analysis
e) Click YES if you see a message asking if you want to open the default graphs.
3. a) Open the Average Transaction Response Time graph .
4. Filter the transactions of the Average Transaction Response Time graph.
In the grid below the graph, uncheck the boxes for all transactions except the ones
in the table below.
Fill in the average transaction response times.
AVERAGE TRANS. RESPONSE TIMES
TRANSACTION 20VUSERS.LRR 25VUSERS.LRR
BookFlight_Transaction
purchase_flight
How much did the average transaction response time vary as more Vusers were
added?
__________________________________________________________________
________________________________________________________________
According to the Throughput graph, how much did the average throughput decline
as more Vusers were added?
__________________________________________________________________
________________________________________________________________
Overall, do you think that the difference between 25 and 20 Vusers was small
enough that you would feel confident allowing the higher load on your system?
__________________________________________________________________
________________________________________________________________
5. When you have finished analyzing the results, save the analysis session as:
\training\loadrunner\Results\cross_results_analysis.
Exercise B: Analyze Results of the 150vusersession.lra File

Correctly diagnosing a problem depends on your interpretation of the LoadRunner
graphs. For this exercise you will use an existing .lra (LoadRunner analysis) file. The
graphs were generated after the first load test run against a Web application.

Results Analysis
Understand the architecture and load testing goal for the Web site before you answer the
questions.
Hypothetical e-commerce Site
• Load Testing Goal —
– Simultaneously perform login, payment image select, and logout with 150
concurrent Vusers.
– The average transaction response time for each of the 3 business processes
should not exceed 16 secs.
• Architecture —
– Web servers: Netscape iPlanet v.4.1 on Solaris 2.7 (Two)
– Application server: BEA WebLogic v5. (One)
– Database server: Oracle 8i running on Sun E420 (Two)
• Business Process Flow/Impact —
– Login and Logout are Database server intensive.
– Payment image select is Application server intensive.
Part 1: Open and Analyze the .lra File
1. Launch the LoadRunner Analysis program.
a) If the LoadRunner main screen is open, click the ANALYZE LOAD TESTS link
from the LOAD TESTING tab. This launches the Analysis program.
b) If the LoadRunner main screen is not open, select MERCURY LOADRUNNER

→ LOADRUNNER from the windows Start menu. This launches the
LoadRunner main screen / launcher program.
c) Omit this step if the Analysis tool is already open.
2. Open the 150VuserSession.lra analysis session.
a) Navigate to \training\loadrunner\Analysis\150VuserSession.lra and

open the file.
b) If you see a warning message, click OK to dismiss it.

Results Analysis
3. Display the “Running Vusers” graph.
a) Click the RUNNING VUSERS tab in the analysis window.
Was the system able to handle the number of concurrent Vusers specified in the
load testing goal?
__________________________________________________________________
________________________________________________________________
4. Merge the Running Vusers graph with the Average Transaction Response Time
graph.
a) Right-click the RUNNING VUSERS graph and select MERGE GRAPHS from the
pop-up menu. The MERGE GRAPHS dialog opens.
b) Choose AVERAGE TRANSACTION RESPONSE TIME from SELECT GRAPH TO

MERGE WITH LIST.
c) Make sure under SELECT TYPE OF MERGE pane OVERLAY is selected.
d) Click OK to merge the graphs and close the MERGE GRAPHS dialog.
How many Vusers were able to run concurrently before the response time goal was
exceeded?
__________________________________________________________________
________________________________________________________________
What could be some of the possible reasons for high response times for the
Payment image select transaction?
__________________________________________________________________
________________________________________________________________
Assume that you are the performance engineer. What steps would you follow to
find the root cause for the high response time of the Payment image select
transaction.
__________________________________________________________________
________________________________________________________________

Results Analysis

Project (Optional)
Appendix A: Project (Optional)
Objectives
This appendix contains the final task that you will perform in this course. This task will
test the skills you learned for building an effective scenario that achieves the defined
performance testing objective. This task is optional.
A-1
Project (Optional)
Building Effective Scenarios

Performance Testing Objective
Company ‘A’ wants to see whether their system will be able to handle 30 users and
achieve the following response times:
Acceptable Poor Unacceptable

Business response response response
Process threshold threshold threshold
(seconds) (seconds) (seconds)
Login up to 8 8 or more 15 or more

PurchaseFlight up to 20 20 or more 25 or more
DisplayItinerary up to 10 10 or more 15 or more
DeleteFlight up to 15 15 or more 20 or more
Acceptable response times means that the test objective was achieved.
Poor response times means that the system or application needs some tuning.
Unacceptable means that the system or application needs to be adjusted and the
scenario needs to be rerun to achieve the test objective.
Your task in this scenario is to determine performance under load. For building this
scenario use the script name ProjectScript located under
\training\loadrunner\Scripts\. For this performance testing objective your
tasks are:
1. Build a Scenario to accomplish the performance test objective.
3. Analyze the scenario results to determine whether or not the performance testing
objectives were achieved.
A-2 Building Effective Scenarios

Project (Optional)
Questions to answer after the test has been run:
1. Specify the Run-time settings you used during the following scenario execution:
Scenario Execution Process Run-time Settings Options Used
Debug run
Isolate Top Time transactions

20% load
Full load test 100%
Scalability 100++%
2. How many Vusers could you run before your CPU usage hits 100%?
______________________________________________________________
______________________________________________________________
3. At what number of Vusers did the Apache servers performance start degrading
below the acceptable response time?
Acceptable Poor Unacceptable

Business response response response Number of
Process threshold threshold threshold Vusers
(seconds) (seconds) (seconds)
Login up to 8 8 or more 15 or more

PurchaseFlight up to 20 20 or more 25 or more
DisplayItinerary up to 10 10 or more 15 or more
DeleteFlight up to 15 15 or more 20 or more
Building Effective Scenarios A-3

Project (Optional)
4. Examine the analysis results and explain whether or not the scenario achieved the
performance testing objective.
______________________________________________________________
______________________________________________________________
A-4 Building Effective Scenarios

Appendix B: Introduction to
Internet Protocols
Objectives
Learn the Internet model used for browser based applications.
B-1
OSI Model (Open Systems Interconnection)
Figure B-1
In any computer program, there is a model that allows the developer to write
applications easily without knowledge of the physical network. The translation from
“what a human wants to see on the screen” to “what a computer or network needs in
order to move data” is handled by this model.
Early applications were developed to follow the OSI model. Internet applications follow
the TCP/IP (Internet) model.
Each layer of the model automatically handles the previous layer. This simplifies
development, since developers no longer need to write code for each layer. For instance,
Web application written to the HTTP standards work whether you are coming from a
Token Ring network or an Ethernet Network. TCP/IP “simplifies” the OSI model to
combine Layers 5-7 into a single “layer”. The suite of “applications” available represent
the different types of applications that move data across the Internet, the need for
reliable transport, and the means of establishing a session. The application layer also
represents the interface to the user, such as Internet Explorer or Netscape Navigator.
Later in this lesson, you will see the importance of the TCP/IP Model to Vugen.
B-2 OSI Model (Open Systems Interconnection)

Figure B-2
A URL (Universal Resource Locator) is a convenient way of formatting requests for

Internet Applications.
Introduction to Internet Protocols B-3

Typical Web Server Port Assignments
Figure B-3
The port number identifies a socket that runs a specific server. Most applications run
under the default port number, but it is possible for a developer to change to a different
port number. If you do not specify a port number in the URL, the browser automatically
directs your requests to a default port. The above table lists some typical Web server
port assignments.
Note: The previous example specified port 80 (which is the default) for HTTP. It is not
necessary to specify the default port. However, if using a “custom port”, it is absolutely
necessary to specify the custom port in the URL.
B-4 Typical Web Server Port Assignments

HTTP/S
• Hyper-Text Transfer Protocol/Secure is the industry standard means of
communicating with web based applications
• Most conversations between a client (Browser) and a server (Web Server) occur via
HTTP/S
• The browser is the link to the Application Layer!
HTTP/S B-5
What does HTTP look like?
Figure B-4
B-6 What does HTTP look like?

What is a Header?
Figure B-5
One of the most important pieces of information returned in a header is the status code.
The status code identifies the nature of the returned response: good or poor.
What is a Header? B-7

HTTP Status Codes
Figure B-6
By checking the header for the status code, we can determine if the web server is
responding well. If we start to see errors (4XX and 5XX), we know that the web server
is not responding well.
Later on, when we start load testing, these errors are the ones that we will be measuring!
B-8 HTTP Status Codes

...And What’s in the Body?

• The body typically contains the resource(s) requested in the URL
• Forms are used to process data using one of two methods
– Get - Generally used to retrieve data such as a search
– Post - Involves storing or changing data, such as ordering a product
...And What’s in the Body? B-9

Browser Functions
• Manages the Application Layer translation from HTTP to HTML
• Renders HTML to a user-friendly display (a Web page)
• Manages the use of connections to the Web server
• Can manage other Internet Protocols such as FTP, Telnet, and SMTP in a common
user interface
The browser is the user interface for requesting resources from the web application.
Initially, users will identify a URL that they wish to interact with, and from that point
they request resources in the context of the application. In other words, users typically
only need to manually request resources one time, and the application formats the
appropriate URLs for any additional requests through the application interface.
As the page is interpreted by the browser, more resource requests may be automatically
issued and downloaded. Typically, a browser can handle 4 simultaneous requests
(connections) at any single time. Any other request must wait for an open connection.
B-10 Browser Functions

HTML
• Hyper-Text Markup Language is the development environment for the Web
• It is the language that Web pages are written (or generated) in
• It may contain additional image, link, test, forms, data...
• It is parsed (interpreted) by the browser to render the Web page returned by the
server
HTML B-11
Summary
• The Internet Model (TCP/IP) is used for browser based applications
• The suite of programs that makes up TCP/IP are HTTP, Telnet, SMTP, POP3, FTP,
etc.
B-12 Summary
Appendix C: Installation
Guidelines When a Firewall is
Present
Objectives
• Identify the issues involved in testing over a firewall
• Use LoadRunner to solve firewall problems
C-1
LoadRunner Controller Inside a Firewall
Figure C-1
When the Controller is inside the firewall, it has direct access to the load generator
machines.
C-2 LoadRunner Controller Inside a Firewall

Working with Firewalls

• When a firewall is present
– Outside communication is blocked
– Only some ports are open
• Mail port (23)
• Web port (80)
How is LoadRunner affected by this?
Working with Firewalls C-3

LoadRunner Controller Outside a Firewall
Figure C-2
When the Controller is outside the firewall, the direct connection between the Controller
and the load generator machine is blocked by the firewall. The connection cannot be
initiated by the Controller because it does not have permission to make an opening in the
firewall.
C-4 LoadRunner Controller Outside a Firewall

LoadRunner Controller Outside a Firewall - cont.
Figure C-3
• Controller’s communication to Load Generator 1 is blocked by the firewall
• Controller has no problem in connecting to Load Generator 2 as it is located

outside the firewall
LoadRunner Controller Outside a Firewall - cont. C-5

LoadRunner Solution
Figure C-4
In order to establish communication between the controller and the load generators, you
need to install MI Listener and the MoFW agent. Normally the MI Listener is installed
on the same machine as the Controller, but it may be on a separate machine (as shown in
the example above). MI Listener and MoFW must be installed on Windows machines.
MI Listener and the Controller may be inside or outside the firewall, but both must be on
the same side of the firewall.
The MoFW (Monitoring Over Firewall) agent connects to MI Listener through port 443
of the firewall. After that connection is established, the Controller connects to MI
Listener through port 50500 of the MI Listener machine. That connection opens
communication through the firewall for the Controller to communicate with load
generators on the other side.
C-6 LoadRunner Solution

LoadRunner Solution - Step 1
Figure C-5
LoadRunner Solution - Step 1 C-7

Figure C-6
C-8 LoadRunner Solution - Step 2

Figure C-7
LoadRunner Solution - Step 3 C-9

Configure the Controller
Figure C-8
C-10 Configure the Controller

Hardware and Software Recommendations
Figure C-9
Hardware and Software Recommendations C-11

C-12 Hardware and Software Recommendations

IP Spoofing
Appendix D: IP Spoofing
Objectives
• Explain how load balancing systems function
• Understand how routing tables and load balancing systems use IP addresses
• Identify the importance of IP Spoofing to load testing
• Implement IP Spoofing in LoadRunner
D-1
IP Spoofing
About IP Spoofing
• IP Spoofing is useful if:
– your system uses a load balancer
– your load balancer uses IP addresses to determine routing
– your IP addresses are static (not assigned using DHCP)
• To implement IP Spoofing you must
– run the IP Wizard from the LoadRunner program group
– enable IP Spoofing in the Controller
IP Spoofing has specific requirements which make it not useful for some systems.
If, for example, your load balancer uses the “least busy” method or the “round-robin”
method, then IP Spoofing is not for you.
D-2 About IP Spoofing

IP Spoofing
D-3
IP Spoofing
The Routing of Web Client Requests is

IP-related
Figure E-1
Some systems employ load balancing configurations to maximize overall speed and
efficiency. Typically, such systems are applied to Web servers and use the IP address of
the originating client to distribute requests.
D-4 The Routing of Web Client Requests is IP-related

IP Spoofing
How are IP Addresses Used by Routing Tables?

• Routing tables identify a packet’s next step by looking up the destination IP address
– Every IP packet is forwarded by hubs, routers, and Web servers by means of a

routing table
How are IP Addresses Used by Routing Tables? D-5

IP Spoofing
Routing Tables Use Destination Addresses to

Find a Packet’s Next Step
Figure D-2
Routers, like hubs and Web servers, know where to send a packet of information. It
references the final destination in its internal routing table and retrieves the IP address of
the packet’s next step.
D-6 Routing Tables Use Destination Addresses to Find a Packet’s Next Step
IP Spoofing
Web Servers Use the Client’s IP Address to

Return Results
Figure D-3
The results of a Web query must be forwarded by the Web server back to the query’s
originator. The client’s IP address is indexed in the Web server’s routing table.
In the example above, the client at 25.20.255.200 sent a request to the Web server
(101.101.101.1), and the request was passed along to the appropriate application and
database servers. Their results were sent back to the Web server, which looked up the
originating client’s IP address, in its routing table. Here the Web server found that
packets to that client should be sent to router 33.33.33.33.
Web Servers Use the Client’s IP Address to Return Results D-7

IP Spoofing
How are IP Addresses Used by Load Balancing

Systems?
• Load Balancing systems specify backend servers based on the IP address which
sent the request
• Load balancing systems use the client IP address to direct queries
D-8 How are IP Addresses Used by Load Balancing Systems?

IP Spoofing
Load Balancing Systems Rely on the IP Address

of the Client
Figure D-4
Each request is sorted by IP address to a back-end destination. In this example, requests

from the three browsers were distributed to three different database servers based on
their IP addresses.
Load Balancing Systems Rely on the IP Address of the Client D-9

IP Spoofing
Virtual Users Generally Reside at a Single IP

Address
Figure D-5
If, during load testing, all requests appear to be originating from a single IP address (or a
narrow range of IP numbers), the load may not be distributed realistically through
various parts of the system.
D-10 Virtual Users Generally Reside at a Single IP Address

IP Spoofing
Unbalanced Load Modeling Causes Uncertain

Test Results
Figure D-6
• An unbalanced load test may invalidate some, if not all, of the test results
Unbalanced Load Modeling Causes Uncertain Test Results D-11

IP Spoofing
D-12
IP Spoofing
IP Spoofing Issues
Figure D-7
• The IP Spoofer feature of LoadRunner is unnecessary when testing systems without

IP-dependent load balancing
IP Spoofing Issues D-13

IP Spoofing
IP Spoofing Issues
Figure D-8
• Because the IP Wizard configures a load generator machine to employ multiple IP

addresses, the wizard must be run on every Vuser load generator machine.
D-14 IP Spoofing Issues

IP Spoofing
The IP Wizard
Figure D-9
By inputting the Web server’s IP address, the IP Wizard can compare this address with
the client IP addresses. If they do not reside on the same network, updates to the routing
table are required.
If the Web server’s IP address is not entered, the server’s routing table must be manually
updated by executing scripts named at the end of the wizard. In practice, it is simpler to
enter the server’s IP address at this point.
The IP Wizard D-15

IP Spoofing
The IP Wizard
Figure D-10
• Clicking the ADD button allows the user to enter IP addresses to be “spoofed”
during scenario execution
• Confirm address validity with the network administrator
D-16 The IP Wizard

IP Spoofing
Add Intranet/LAN Addresses
Figure D-11
• When testing an intranet or a small LAN system, enter a range of numbers to represent
users on this closed system
• Select Class A, B, or C according to the numbering convention used on the network
Add Intranet/LAN Addresses D-17

IP Spoofing
Add Internet Addresses
Figure D-12
• To simulate usage from many parts of the Internet, select the DON’T USE ANY OF THESE
option and enter several completely unique IP addresses
• Consult the network administrator responsible for the load balancing system to learn which
IP addresses can be used to create a balanced load across the entire system
D-18 Add Internet Addresses

IP Spoofing
The IP Wizard
Figure D-13
• To ensure an automatic update of the Web server’s routing table, check the appropriate box
at the end of the wizard
The IP Wizard D-19

IP Spoofing
Implementing the IP Spoofer
Figure D-14
• After the Web server has been rebooted, open the Controller and enable the IP Spoofer
from the Scenario menu
D-20 Implementing the IP Spoofer

IP Spoofing
Implementing the IP Spoofer
Figure D-15
Implementing the IP Spoofer D-21

IP Spoofing
IP Spoofing Results in Well-Distributed Load

Modeling
Figure D-16
During load testing with the IP Spoofer enabled, requests seem to originate from a
spectrum of client addresses. Consequently, the entire system is realistically tested.
D-22 IP Spoofing Results in Well-Distributed Load Modeling

IP Spoofing
Summary
• IP Addresses
– Used by routing tables to determine an IP packet’s path
– Used by load balancing systems to divide a load among several backend

servers
• IP Spoofing
– Emulates real-world network traffic
– Associates each Vuser with a different IP address
– Is confirmed by running the IP Wizard
– Must be configured separately on every Vuser load generator
Summary D-23
IP Spoofing
D-24 Summary
Class Evaluation Form
(http://www.merc-training.com/survey/publictraining)
Class: _____________________________ Class Start Date: ______________
Location: ____________________ Instructor: ______________________
1. How did you register for this class? (check one)
On-line
Through a Resource Coordinator
Someone else registered me
2. How much do you agree with the following statements regarding the registration process and facility?
(Please circle only one rating for each category):
Strongly Strongly
Agree Neutral Disagree N/A
Agree Disagree
My registration was handled efficiently. 5 4 3 2 1 -
The classroom/facilities were clean and well 5 4 3 2 1 on-site
maintained.
The classroom equipment worked properly and 5 4 3 2 1 on-site
effectively supported the class.
3. How could the registration process or facilities be improved?
4. If there was CBT pre-work that was to be completed before class, did you complete it?
There was no CBT pre-work for this class

Yes - I completed it before class
No - I didn't understand that it was required
No - I didn't get the assignment in time
No - I didn't have time to do it
No - Skipped it, already familiar with the content
No - Couldn't figure out the CBT site
No - I started, but the content didn't seem useful
5. If you completed CBT pre-work for this class, how helpful was it in preparing you for this class?
Very helpful Somewhat helpful I’m not sure Not very helpful Not helpful at all
5 4 3 2 1
6. How would you rate your technical ability going into the class?
5 - Highly technical
4 - Above average
3 - Average
2 - Below average
1 - Not at all technical
7. How would you rate your familiarity with the product going into the class?
5 - I consider myself a product expert

4 - I have above average knowledge of the product
3 - I'm comfortable with common product functions
2 - I've used the product a little
1 - I've never used the product
8. How much do you agree with the following statements regarding the course content and materials?
Strongly Strongly
Agree Neutral Disagree
Agree Disagree
The objectives laid out in the course description were met. 5 4 3 2 1
The course materials were clearly written and easy to follow. 5 4 3 2 1
There was an appropriate amount of content - not too packed 5 4 3 2 1
or too lean.
The lab exercises were well constructed and relevant. 5 4 3 2 1
The graphics in the course materials were clear and effective. 5 4 3 2 1
I would recommend this course to others. 5 4 3 2 1
9. How could the course materials be improved?

10. How much do you agree with the following statements regarding the class instructor?
Strongly Strongly
Agree Neutral Disagree
Agree Disagree
The instructor had a thorough knowledge of the course 5 4 3 2 1
content.
The instructor encouraged participation from students. 5 4 3 2 1
The instructor was an effective communicator. 5 4 3 2 1
The instructor conducted the class at an appropriate pace.
The instructor made the course relevant by using real- 5 4 3 2 1
world examples.
I would recommend this instructor to others. 5 4 3 2 1
11. What suggestions do you have for the instructor?
12. How would you rate your overall experience with this class?
Excellent Good OK Needs Improvement Poor

5 4 3 2 1
13. What is your level of confidence after completing the class?
I understood the I understood the

I understood the
course concepts, and course concepts, can
course concepts, but I understood some of I had a very hard time
can apply most of apply some without
will need help the course concepts with this course
them without assistance, but will
applying them
assistance need help with others
5 4 3 2 1
14. What recommendations do you have to improve the overall effectiveness of this course?
15. What other courses would you like to see offered by Mercury Education Services?
16. If you have any other comments, please enter them below. If you would like to be contacted regarding
your comments, please include your name and contact information.

LR81 Student 01D

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

LR81 Student 01D

Hochgeladen von

Copyright:

Verfügbare Formate

Fundamentals of LoadRunner

© Copyright 1994 - 2005 by

Planning an Effective Load Test

Using Run-time Settings

Introduction to Internet Protocols

Installation Guidelines When a Firewall is Present

• Explain the need for load testing.

• Describe various types of performance test objectives.

• Identify the steps of the LoadRunner methodology.

• Define the term “scenario” in the context of LoadRunner.

After completing this course, you will be able to:

• Identify what information needs to be gathered for load testing.

• Identify the components of LoadRunner.

• Apply the workflow recommended for creating a basic LoadRunner scenario.

• Load test your application by running a scenario.

1-2 Course Objectives

Why Load Test your Application?

• Preventing costly failures of mission-critical applications.

• Assuring performance and functionality under real-world conditions.

• Locating potential problems before your customers do.

• Reducing development time.

• Reducing infrastructure costs.

Why Load Test your Application? 1-3

Types of Performance Testing

Figure 1-1 Types of performance testing

1-4 Types of Performance Testing

Examples of Performance Test Objectives

Performance Test Objective Explanation

Application response time How long does it take to complete a task?

Examples of Performance Test Objectives 1-5

Load Testing in the Product Life Cycle

Load testing is necessary throughout the product life cycle.

1-6 Load Testing in the Product Life Cycle

Manual Testing is Problematic

Figure 1-3 Problems of manual load testing

• How can site developers generate enough load to enable testing?

• How can I obtain sufficient testing personnel and client machines?

• How can I synchronize users?

• How do I measure the results?

Manual Testing is Problematic 1-7

The LoadRunner Solution

Figure 1-4 LoadRunner’s load testing solution

1-8 The LoadRunner Solution

The LoadRunner Methodology

Figure 1-5 The LoadRunner methodology

LoadRunner is a complete solution for conducting automated load testing before,

– Scale the application to a predetermined capacity

– Identify business processes or system components having trouble

– Diagnose a problem to pinpoint the root cause

The LoadRunner Methodology 1-9

LoadRunner’s Load Testing Components

Figure 1-6 Load testing components

1-10 LoadRunner’s Load Testing Components

The LoadRunner Launch Screen

Figure 1-7 The LoadRunner launch screen

The LoadRunner Launch Screen 1-11

The LoadRunner Scripting Component

Figure 1-8 The LoadRunner scripting component

1-12 The LoadRunner Scripting Component

Figure 1-9 The LoadRunner Vuser

What is a Vuser? 1-13

Figure 1-10 Supported Protocols

1-14 Supported Protocols