1) Easy to use
tool
2) Learning curve for a beginner is very low compared with the other tool
3) Vast variety of application and protocol support
4) Scripting is very easily done by using VuGen
5) The load test can be designed exactly similar to realistic loads tests using manual scenarios
6) The load tests can also be designed based on the goals of the customer, by way of goal oriented scenarios
7) The service level agreements or objectives can be set and will be evaluated during the load test analysis phase
8) The results can be easily analyzed and comparison graphs and reports can be generates using analysis component
9) The loads can be generated using different remote load generators with more number of users by way multiple thread mechanism
10) Support from HP is good.
11) There is lots of online help and forums available for any issues
12) The resources for loadrunner is also easy to get in the industry
2) Learning curve for a beginner is very low compared with the other tool
3) Vast variety of application and protocol support
4) Scripting is very easily done by using VuGen
5) The load test can be designed exactly similar to realistic loads tests using manual scenarios
6) The load tests can also be designed based on the goals of the customer, by way of goal oriented scenarios
7) The service level agreements or objectives can be set and will be evaluated during the load test analysis phase
8) The results can be easily analyzed and comparison graphs and reports can be generates using analysis component
9) The loads can be generated using different remote load generators with more number of users by way multiple thread mechanism
10) Support from HP is good.
11) There is lots of online help and forums available for any issues
12) The resources for loadrunner is also easy to get in the industry
The types of load testings
supported by loadrunner are:
Load Testing: By using the loadrunner the load test can be simulated for multiple
simultaneous users, similar to realistic number of
users.
Endurance / Longevity /
Soak Testing: By
using the loadrunner the load
test can be simulated for longer
durations
Stress
Testing: By using the loadrunner the load test can be simulated with multiple users
till the stress point reaches with incremental increase in the number of users.
Spike Testing: By using the loadrunner, during
the load test execution spikes can introduced by way
of adding thenumber of users.
Capacity Testing: Using loadrunner systems
capacity can be tested for the future incremental in business. For example, if
the current AUT system configuration supports 1000 users. Due to the expansion
in business, if the numberof
users are increased to 10000. Does the existing environment supports or any new
systems to be procured. The decision can be taken by way of conducting the load tests using load runner.
Scalability
Testing: Scalability can be compared
using some of the auto generated graphs, like average response times under
load.
The scenario
types available in loadrunner controller are:
1) Manual scenario
2) Manual scenario by percentage
3) Goal oriented scenario
1) Manual scenario
2) Manual scenario by percentage
3) Goal oriented scenario
Goal Oriented scenario is one type of load test scenario in controller.
Goal Oriented scenario is used
for creating the scenario based on the customer expected objectives.
For example: if the customer
wants to achieve the 100 hits per second with variable number of users like
minimum number of users 50 and maximum number of users 150. Then you may need
to select the type of load test as goal oriented.
Normally the goal oriented
scenario should be executed for long durations to achieve the customer goals or
objectives.
Manual scenario is one of the
types of load runner scenarios. This will be used for simulating the real time load tests.
The manual scenario can be built
by creating groups and specifying the script, the load generator, and the
number of Vusers included in each group
5.
What
is the difference between manual scenario and goal oriented scenario in
loadrunner controller?
|
Manual scenario
|
Goal oriented scenario
|
|
Used to simulate the real time loads based on the fixed time
and fixed number of virtual users
|
Used for simulating the load, based on the
objectives defined by the customer expected objectives like HTTP hits,
transactions per sec and transaction response time etc.
|
|
The duration is fixed. Since the time clearly defined in real
world scehdules
|
The duration is always much more than the duration mentioned
in goal oriented scenarios. Since the goal will be achieved after the mentioned
time
|
|
Acceleration and deceleration of the users will
happen based on theschedule design
|
Acceleration and deceleration of the users will
happen automatically, based on the goal defined
|
Goal oriented scenario:
The goal oriented scenario is selected, only when you want to simulated the customer objectives or goals like HTTP hits per second or transactions per second or transaction response time.
The goal oriented scenario is selected, only when you want to simulated the customer objectives or goals like HTTP hits per second or transactions per second or transaction response time.
Manual scenario:
Manual scenario will selected when you want to simulate the number of virtual users according to the real time load behavior of the users.
Manual scenario will selected when you want to simulate the number of virtual users according to the real time load behavior of the users.
1)
From controller Select menu option
File -> New
2) New Scenario Dialog box pops up
3) Select the goal oriented scenario radio button
4) Add the appropriate scripts
5) Click OK button
6) New scenario opens in the controller
7) Click on "Edit scenario goal" button in scenario goal
8) Edit scenario goal pops up
9) Click on New button
10) New Goal profile dialog opens
11) Enter the name and press OK
12) Now, you can set the new profile settings
2) New Scenario Dialog box pops up
3) Select the goal oriented scenario radio button
4) Add the appropriate scripts
5) Click OK button
6) New scenario opens in the controller
7) Click on "Edit scenario goal" button in scenario goal
8) Edit scenario goal pops up
9) Click on New button
10) New Goal profile dialog opens
11) Enter the name and press OK
12) Now, you can set the new profile settings
To define Scenario Goal, we
choose different types of goals based on the customer given objectives for the load test.
There are 5 types of goals available. Select the type of goal you want for the scenario.
There are 5 types of goals available. Select the type of goal you want for the scenario.
Pages per Minute (for
Web Vusers only). Enter a
target number of downloaded pages
per minute that you would like your scenario to reach, and select a minimum and maximum number of Vusers
for the scenario.
Virtual Users. Enter a target number of
virtual users that you would like your scenario to reach.
Hits per Second (for Web
Vusers only). Enter a
target number of hits per second (HTTP requests per
second) that you would like your scenario to reach, and select a minimum and maximum number of Vusers
for the scenario.
Transactions per Second. Enter a target number of
transactions per second that you would like your scenario to reach, and select a minimum and maximum number of Vusers
for the scenario.
Transaction Response
Time. Enter a
target transaction response time that you would like your scenario to reach,
andselect a minimum and maximum
number of Vusers for the scenario.
Using the load behavior tab,
you can set when the ramp up to achieve the goal.
The ramp up can be set in three ways
Automatic. Instructs the Controller to
run the default number of Vusers in a batch. Controller starts with the minimum
number of Vusers. And runs for two minutes. If the goal is not achievable, the
scenario automatically increases the users to achieve the goal.
Reach target X after. Select the amount of scenario time you want
to elapse before the Controller reaches your target. This is the
minimum time you have given. The
controller takes much larger time
than mentioned here.
Step up by (not available for the Transactions per Second
and Transaction Response Time goal types). Select the gradation according to which you
want the Controller to reach your target (x number of
virtual users/hits/pages every x amount of time).
There is a check box Do
not change recorded think time in Edit scenario goal. If it is not
checked, the controller will minimize the think time, and runs the load
test. So, due to reduction in think time the frequency
of the hits will increase.
Note: If you select this option, you may need to increase the number of Vusers in your scenario in order to reach your target
Note: If you select this option, you may need to increase the number of Vusers in your scenario in order to reach your target
Goal oriented scenario
scenarios will execute based on the goals defined. The main objective of the
goal oriented scenario is to maintain the goal throughout the load test execution.
For example: You are running
goal oriented scenario with the goal of 100 hits per second, with minimum
number of users as 50 and maximum number of users as 150. If the actual hits
per second is coming around 75, when the load test is running with 50 users, then the
controller automatically increases the number of users based on the required
hits. When the number of hits are above the goal, then the number of users will
be decreased accordingly
13.
What are the options can be chosen if the load target is not reachable in
loadrunner controller?
During the goal oriented
scenario profile creation, you have to select the appropriate option
for continuation or termination of load test, if the goal is not
achievable.
There are two options available to choose for
non-achievable goals:
Stop scenario and save
results. Instructs the
Controller to stop the scenario and save the scenario results, if the target
you defined cannot be reached.
Continue scenario without reaching goal. Instructs the Controller to continue
running the scenario, even if the target you defined cannot be reached.
If you want to get notified during the goal
oriented scenario, if the goal is not reachable. Select the option
Receive notification. Instructs the Controller to send you an error message indicating that the target cannot be reached.
Receive notification. Instructs the Controller to send you an error message indicating that the target cannot be reached.
Load generator Load generator is a
component of loadrunner. Load generator is used for creation of the virtual
users.
Load generators can be added to controller
with the below mentioned steps.
1) Select the menu
option "Scenario -> Load generators" in controller
2) Load generators dialog box opens
3) Click on Add button
4) Enter the name or ip address of the load generator
5) Select the platform Windows or UNIX
6) Enter the temporary directory
7) Click OK button
2) Load generators dialog box opens
3) Click on Add button
4) Enter the name or ip address of the load generator
5) Select the platform Windows or UNIX
6) Enter the temporary directory
7) Click OK button
The operating systems supported by load generator are:
1) Windows
2) UNIX
1) Windows
2) UNIX
If you have not mentioned the temporary folder for load generator, the
results will be stored in the mentioned folder.
Otherwise, the load generator is going to store the results in the temporary folder in the current user profile as:C:\Documents and Settings\<user name>\Local Settings\Temp\.
Otherwise, the load generator is going to store the results in the temporary folder in the current user profile as:C:\Documents and Settings\<user name>\Local Settings\Temp\.
To see the actual folder, open
the load generator details, and see the temporary folder to get the actual folder name with
full path.
To check the load generators
1) Select the load generator and click on connect
2) Observe the status of the load generator
3) If the load generator status is ready, that means the load generator can be used for execution of the load test
4) If the load generator status is failed, that means that load generator is not ready for execution
1) Select the load generator and click on connect
2) Observe the status of the load generator
3) If the load generator status is ready, that means the load generator can be used for execution of the load test
4) If the load generator status is failed, that means that load generator is not ready for execution
The group is combination of
VuGen test script, number of virtual users and the load generator.
Each group can also be
associated with its own run time settings.
Yes, the same script can be used part of the multiple groups.
Click on Add group from the
controller scenario. When you choose same script from the test script list,
every time you add the test script, load runner generates different name for
the group by suffixing a number. You can change the name of the group while
adding the test script.
In the scenario group section
there is a load generator group column.
Associate each of the load
generator with each group.
A group can be added to the
scenario with the below mentioned steps:
1) Click on Add group button
2) Enter the name of the group
3) Enter the number of Vusers quantity
4) Select the load generator
5) Select the script to be part of the group
6) Press OK
1) Click on Add group button
2) Enter the name of the group
3) Enter the number of Vusers quantity
4) Select the load generator
5) Select the script to be part of the group
6) Press OK
Now your new group has been
added to the scenario
Users from a group can be deleted with the
below mentioned steps:
1) Select the group from the controller scenario
2) Click on the vuser group button
3) Select the number of users needs to be deleted
4) Press the Delete key from your keyboard
1) Select the group from the controller scenario
2) Click on the vuser group button
3) Select the number of users needs to be deleted
4) Press the Delete key from your keyboard
A single user can be executed on a specific
load generators with the below mentioned steps:
1) Select the group from the controller scenario
2) Click on the vuser group button
3) Select the Vuser, the vuser could have been pointed to the script and load generator
4) Click on run button. The selected vusers will be executing
1) Select the group from the controller scenario
2) Click on the vuser group button
3) Select the Vuser, the vuser could have been pointed to the script and load generator
4) Click on run button. The selected vusers will be executing
Enable Rendezvous/Disable
Rendezvous : Enables or disables the selected rendezvous points from
participating in the scenario.
The rendezvous option will be
enabled or disabled with the below mentioned steps:
1) Open the controller scenario
2) Select the menu option scenario -> Rendezvous...
3) Rendezvous Information dialog box opens
4) Select the name of Rendezvous point
5) Click on Enable (or Disable) Rendezvous button
1) Open the controller scenario
2) Select the menu option scenario -> Rendezvous...
3) Rendezvous Information dialog box opens
4) Select the name of Rendezvous point
5) Click on Enable (or Disable) Rendezvous button
Policy.
Opens the Policy dialog box, enabling you to set how many Vusers are released from a rendezvous at a time, as well as the amount of time the Controller waits before releasing Vusers from a rendezvous.
Opens the Policy dialog box, enabling you to set how many Vusers are released from a rendezvous at a time, as well as the amount of time the Controller waits before releasing Vusers from a rendezvous.
The options are:
1) Release when 100% of all vusers arrive at the rendezvous
2) Release when 100% of all running arrive vusers at the rendezvous
3) Release when number of vusers arrive at the rendezvous
1) Release when 100% of all vusers arrive at the rendezvous
2) Release when 100% of all running arrive vusers at the rendezvous
3) Release when number of vusers arrive at the rendezvous
Timeout. Enter the timeout value (in
seconds). After each Vuser arrives at the rendezvous point, LoadRunner waits up
to the number of timeout seconds specified for the next Vuser to arrive. If the next Vuser does not arrive within the
timeout period, the
Controller releases all
the Vusers from the rendezvous. Each time a new Vuser arrives, the timer is
reset to zero. The default timeout is thirty.
Timeout is set based on the
execution time of the virtual users.
Enable Rendezvous/Disable
Rendezvous : Enables or disables the selected rendezvous points from
participating in the scenario.
The rendezvous option will be
enabled or disabled
with the below mentioned
steps:
1) Open the controller scenario
2) Select the menu option scenario -> Rendezvous...
3) Rendezvous Information dialog box opens
4) Select the name of Rendezvous point
5) Click on Enable (or Disable) Rendezvous button
1) Open the controller scenario
2) Select the menu option scenario -> Rendezvous...
3) Rendezvous Information dialog box opens
4) Select the name of Rendezvous point
5) Click on Enable (or Disable) Rendezvous button
Scenario start time can be set with the below
mentioned steps
1) Open the manual scenario
2) Click on Start time button on Scenario Schedule
3) Enter the start scenario time
1) Open the manual scenario
2) Click on Start time button on Scenario Schedule
3) Enter the start scenario time
a) without a delay
b) with a delay of
c) at a specific time
b) with a delay of
c) at a specific time
There are two types of
schedules available in scenario. Those are
1) Schedule by scenario
schedule the scenario to start running at a specified time. You can
limit the execution duration of the scenario or of a Vuser group within the
scenario.
You can also stipulate how many
Vusers to start and stop running within
a certain time frame. You can specify whether LoadRunner should start or stop running all Vusers in a scenario
simultaneously, or only a certain number of Vusers within a specified amount of
time.
2) Schedule by group
For each enabled Vuser group in
a scenario, you can design a separate execution schedule. You can specify when to start running the Vuser group, how many
Vusers to start and stop
running within given time
intervals, and how long the Vuser group should continue running.
Scenario creation types can be seen
with the link What are the types of run modes
available in loadrunner controller scenario schedule?
For each of the above, the run
modes are:
1) Run by Real
word schedule
The scenario runs according to a user-defined group of actions that simulate a real-world schedule of events. Vuser groups run according to the iterations defined in their run-time settings, but you can define how many Vusers to run at a time, how long Vusers should continue to run, and how many Vusers to stop running at a time.
The scenario runs according to a user-defined group of actions that simulate a real-world schedule of events. Vuser groups run according to the iterations defined in their run-time settings, but you can define how many Vusers to run at a time, how long Vusers should continue to run, and how many Vusers to stop running at a time.
2) Run by Basic
schedule (or until complete in older versions)
All enabled Vuser groups run together on one schedule, each according to its own run-time settings. You can schedule how many Vusers to start running at a time, how long to run the Vusers, and how many Vusers to stop running at a time.
All enabled Vuser groups run together on one schedule, each according to its own run-time settings. You can schedule how many Vusers to start running at a time, how long to run the Vusers, and how many Vusers to stop running at a time.
The actions available in loadrunner controller
scenario are:
1) Start Group The Start Group action defines when to start running a Vuser group. This action is available for group schedules only.
1) Start Group The Start Group action defines when to start running a Vuser group. This action is available for group schedules only.
Note: By default, the Start
Group action appears as the first action in the Actions grid when you select Schedule by: Group. It is always followed by
the Initialize action. It cannot
be deleted.
2) Initialize
The Initialize action instructs LoadRunner to prepare the Vusers so that they are in the Ready state and can run.
The Initialize action instructs LoadRunner to prepare the Vusers so that they are in the Ready state and can run.
Note: By default, the
Initialize action appears in the Actions grid for all schedule types. It cannot be deleted.
3) Start
Vusers
The Start Vusers action instructs LoadRunner to start running Vusers.
The Start Vusers action instructs LoadRunner to start running Vusers.
4) Duration
The Duration action instructs LoadRunner to continue running the scenario in the current state, for the specified amount of time.
The Duration action instructs LoadRunner to continue running the scenario in the current state, for the specified amount of time.
5) Stop
Vusers
The Stop Vusers action instructs LoadRunner to stop the running Vusers.
The Stop Vusers action instructs LoadRunner to stop the running Vusers.
The options available in loadrunner controller scenario are:
Initialize all Vusers
simultaneously
LoadRunner initializes all the Vusers in the scenario or selected Vuser group together, before running them.
LoadRunner initializes all the Vusers in the scenario or selected Vuser group together, before running them.
Initialize XX Vusers
every <00:00:00> (HH:MM:SS)
LoadRunner initializes the specified number of Vusers gradually before running them, according to the specified time interval (in hours, minutes, and seconds).
LoadRunner initializes the specified number of Vusers gradually before running them, according to the specified time interval (in hours, minutes, and seconds).
Initialize each Vuser
just before it runs
(Default) LoadRunner initializes each Vuser in the scenario or selected Vuser group just before it starts running.
(Default) LoadRunner initializes each Vuser in the scenario or selected Vuser group just before it starts running.
Note: The above option is not available for Group schedules when the Wait for all groups to
initialize option is selected.
See Initializing All Vuser Groups Before a Run.
Start XX Vusers: Simultaneously
(Default)
LoadRunner runs the specified number of Vusers simultaneously
LoadRunner runs the specified number of Vusers simultaneously
Start XX Vusers: YY Vusers every
<00:00:00> (HH:MM:SS) LoadRunner
runs the specified number of Vusers (XX) gradually. That is, LoadRunner runs YY
Vusers, and waits the specified time (in hours, minutes, and seconds) before
running another YY Vusers.
Run until completion
The scenario runs until all the Vusers have finished running.
Note: In a Real-world schedule, this option is available after the first time the Vusers start running only.
The scenario runs until all the Vusers have finished running.
Note: In a Real-world schedule, this option is available after the first time the Vusers start running only.
Run for XX days and
<00:00:00> (HH:MM:SS)
The scenario runs in its current state for the specified amount of time (in days, hours, minutes, and seconds) before continuing with the next action.
The default Duration period is 5 minutes.
The scenario runs in its current state for the specified amount of time (in days, hours, minutes, and seconds) before continuing with the next action.
The default Duration period is 5 minutes.
Run indefinitely
(Basic schedule only) The scenario runs indefinitely.
(Basic schedule only) The scenario runs indefinitely.
Stop vusers action of global
schedule will be having the following options:
Stop XX Vusers:
Simultaneously
(Default) LoadRunner stops the specified number (All or XX) of running Vusers at once.
(Default) LoadRunner stops the specified number (All or XX) of running Vusers at once.
Stop XX Vuser: YY Vusers
every <00:00:00> (HH:MM:SS)
LoadRunner stops the specified number of Vusers (All or XX) gradually. That is, LoadRunner stops YY Vusers, and waits the specified time (in hours, minutes, and seconds) before stopping another YY Vusers.
LoadRunner stops the specified number of Vusers (All or XX) gradually. That is, LoadRunner stops YY Vusers, and waits the specified time (in hours, minutes, and seconds) before stopping another YY Vusers.
The action types available in loadrunner
controller scenario are:
1) Start
Vusers
The Start Vusers action instructs LoadRunner to start running Vusers.
The Start Vusers action instructs LoadRunner to start running Vusers.
2) Duration
The Duration action instructs LoadRunner to continue running the scenario in the current state, for the specified amount of time.
The Duration action instructs LoadRunner to continue running the scenario in the current state, for the specified amount of time.
3) Stop
Vusers
The Stop Vusers action instructs LoadRunner to stop the running Vusers.
The Stop Vusers action instructs LoadRunner to stop the running Vusers.
1) Start
Group The
Start Group action defines when to start running a Vuser group. This action is
available for group schedules only.
Note: By default, the Start
Group action appears as the first action in the Actions grid when you select
Schedule by: Group. It is always followed by the Initialize action. It cannot
be deleted.
2) Initialize
The Initialize action instructs LoadRunner to prepare the Vusers so that they are in the Ready state and can run.
The Initialize action instructs LoadRunner to prepare the Vusers so that they are in the Ready state and can run.
Note: By default, the Initialize
action appears in the Actions grid for all schedule types. It cannot be
deleted.
3) Start
Vusers
The Start Vusers action instructs LoadRunner to start running Vusers.
The Start Vusers action instructs LoadRunner to start running Vusers.
4) Duration
The Duration action instructs LoadRunner to continue running the scenario in the current state, for the specified amount of time.
The Duration action instructs LoadRunner to continue running the scenario in the current state, for the specified amount of time.
5) Stop
Vusers
The Stop Vusers action instructs LoadRunner to stop the running Vusers.
The Stop Vusers action instructs LoadRunner to stop the running Vusers.
the options available in loadrunner controller
scenario Start group action are:
In the Start/Stop Vusers box, enter the number
of Vusers to start/stop running, and select whether to:
start/stop running all
the Vusers simultaneously
start/stop running the Vusers gradually
start/stop running the Vusers gradually
In this case, enter the number of Vusers to
start/stop at a time, and at what time interval
The results folder to write the results in a
specific folder will be done with the below mentioned steps:
1) Select the menu options Results -> Results Settings...
2) Set Results Settings Directory Dialog box opens
3) Enter the "Results Name"
4) Enter the Directory path
1) Select the menu options Results -> Results Settings...
2) Set Results Settings Directory Dialog box opens
3) Enter the "Results Name"
4) Enter the Directory path
The user status will change as mentioned in
the order of sequence:
1) Down The
Vuser is down.
2) Pending The Vuser is ready to be initialized and is waiting for an
available load generator, or is transferring files to the load generator. The Vuser will run when the conditions set in its scheduling attributes are met.
3) Initializing The Vuser is being initialized on the remote machine.
4) Ready The Vuser already performed the init section of the script and is ready to run.
5) Running The Vuser is running. The Vuser script is being executed on a load generator.
6) Rendezvous The Vuser has arrived at the rendezvous and is waiting to be released by LoadRunner.
6) Done.Passed The Vuser has finished running. The script passed.
7) Done.Failed The Vuser has finished running. The script failed.
8) Error A problem occurred with the Vuser. Check the Status field on the Vuser dialog box or the output window for a complete explanation of the error.
9) Gradual Exiting The Vuser is completing the iteration or action it is running (as defined in Tools > Options > Run-Time Settings) before exiting.
10) Exiting The Vuser has finished running or has been stopped, and is now exiting.
11) Stopped The Vuser stopped when the Stop command was invoked.
2) Pending The Vuser is ready to be initialized and is waiting for an
available load generator, or is transferring files to the load generator. The Vuser will run when the conditions set in its scheduling attributes are met.
3) Initializing The Vuser is being initialized on the remote machine.
4) Ready The Vuser already performed the init section of the script and is ready to run.
5) Running The Vuser is running. The Vuser script is being executed on a load generator.
6) Rendezvous The Vuser has arrived at the rendezvous and is waiting to be released by LoadRunner.
6) Done.Passed The Vuser has finished running. The script passed.
7) Done.Failed The Vuser has finished running. The script failed.
8) Error A problem occurred with the Vuser. Check the Status field on the Vuser dialog box or the output window for a complete explanation of the error.
9) Gradual Exiting The Vuser is completing the iteration or action it is running (as defined in Tools > Options > Run-Time Settings) before exiting.
10) Exiting The Vuser has finished running or has been stopped, and is now exiting.
11) Stopped The Vuser stopped when the Stop command was invoked.
Service level agreements (SLAs)
enable you to define goals for your load test scenario.
During a scenario run, the Controller measures the performance and collects data.
Analysis compares this data against thresholds defined in the SLAs.
During a scenario run, the Controller measures the performance and collects data.
Analysis compares this data against thresholds defined in the SLAs.
There are two types of Service Level
Agreements available
SLA status determined at time intervals over a timeline. Analysis displays SLA statuses at set time intervals—for example, every 10 seconds—over a timeline within the run.
SLA status determined at time intervals over a timeline. Analysis displays SLA statuses at set time intervals—for example, every 10 seconds—over a timeline within the run.
1) SLAs for Average
Transaction Response Time
2)SLAs for Errors Per Second.
2)SLAs for Errors Per Second.
SLA status determined over the whole
run. Analysis displays a
single SLA status for the whole scenario run.
The analysis displays a single SLA status for
the whole scenario run:
1) Total Hits per run
2) Average Hits (hits/second) per run
3) Total Throughput (bytes) per run
4) Average Throughput (bytes/second) per run
2) Average Hits (hits/second) per run
3) Total Throughput (bytes) per run
4) Average Throughput (bytes/second) per run
The types of load criteria’s available in
goal definition are:
1) None
2) Running vusers
3) Hits per second
4) Throughput
5) Transactions per second
6) Transactions per second pass
2) Running vusers
3) Hits per second
4) Throughput
5) Transactions per second
6) Transactions per second pass
Thresholds are nothing but the maximum
wait points.
Set maximum thresholds for each
transaction that you are evaluating.
If you defined
load criteria in the previous step, you set thresholds for
each transaction per the defined load value ranges.
If you did not define load criteria, you
set a single threshold for each transaction.
Enter the relevant thresholds (per
load criteria, if defined) in the table displayed at the top the
page.
You can edit an existing service level
agreement
1) Select the Service level agreement in the existing Service level agreement area
2) Click on edit button
3) Service level agreement goal definition window will pop up
4) Edit the goal definition as needed
1) Select the Service level agreement in the existing Service level agreement area
2) Click on edit button
3) Service level agreement goal definition window will pop up
4) Edit the goal definition as needed
No, the type of service level
agreement cannot be changed.
Once we select the type of
service level agreement, the same type will be used in all the cases.
If you want to change the type.
The existing service level agreement needs to be deleted. And the new service
level agreement needs to be created.
LoadRunner enables you to view
data generated during scenario execution using the online monitors. You specify
the machines that the Controller will monitor during a scenario execution, and
view the data collected by the monitors, using the LoadRunner online graphs.
A primary factor in a
transaction's response time is its resource usage. By monitoring resources
during a scenario run, you can determine why a bottleneck occurred on a
particular machine. LoadRunner's server resource monitors let you keep track of
resources used during a scenario. LoadRunner displays the selected resource
monitors in real time during test execution. You can select the server resource
measurements to monitor both before and during the scenario.
The online monitors are divided
into the following categories:
Run-Time Monitors. Display the number and status
of Vusers participating in the scenario, as well as the number and types of
errors that the Vusers generate.
Transaction Monitors. Display the transaction rate
and response time during scenario execution.
Web Resource Monitors. Provide information about the
number of Web connections, throughput volume, HTTP responses, server retries,
and pages downloaded to the Web servers during the scenario.
System Resource
Monitors. Measure
the Windows, UNIX, Tuxedo, SNMP, and SiteScope resources used during a scenario.
Network Delay Monitor. Displays information about the
network delays on your system.
Firewall Monitor. Measures statistics of the
firewall servers during the scenario.
Web Server Resource
Monitors. Measure
statistics of the Microsoft IIS, iPlanet (SNMP), and iPlanet/Netscape Web
servers during the scenario.
Web Application Server
Resource Monitors. Measure
statistics of the Ariba, iPlanet (NAS), Microsoft ASP, WebLogic (SNMP), and
WebSphere application servers during the scenario.
Database Server Resource Monitors. Measure statistics of the SQL
server, Oracle, and DB2 databases during
the scenario.
Streaming Media
Monitors. Measure
statistics of the RealPlayer and Media Player client during the scenario.
ERP/CRM Server Resource
Monitors. Measure
statistics of the SAP Portal, SAP CCMS, SAPGUI, Siebel Server Manager,
Siebel Web Server, and PeopleSoft (Tuxedo)
servers during the scenario.
Java Performance Monitor. Measures statistics of Java 2 Platform,
Enterprise Edition (J2EE) objects, and Java-based applications, using J2EE
machines.
J2EE & .NET Diagnostics
Monitors. Provide
information to trace, time, and troubleshoot individual transactions through
J2EE & .NET Web, application, and database servers.
Application Component Monitor. Measures statistics of the
Microsoft COM+ server during a scenario run.
Application Deployment
Solutions Monitor. Measures statistics of the
Citrix MetaFrame XP and 1.8 servers during a scenario run.
Middleware Performance
Monitors. Measure
statistics of the
Tuxedo and IBM WebSphere MQ servers during a scenario run.
Infrastructure Resources Monitor. Measures statistics of the
network client data points during a scenario run.
The monitors used for
validating client side measures of the load test are:
Run-Time Monitors. Display the number and status
of Vusers participating in the scenario, as well as the number and types of
errors that the Vusers generate.
Transaction Monitors. Display the transaction rate
and response time during scenario execution.
Web Resource Monitors. Provide information about the
number of Web connections, throughput volume, HTTP responses, server retries,
and pages downloaded to the Web servers during the
scenario.
The monitors used during the
load test for evaluating the servers performance are:
System Resource
Monitors. Measure
the Windows, UNIX, Tuxedo, SNMP, and SiteScope resources used during a scenario.
Network Delay Monitor. Displays information about the
network delays on your system.
Firewall Monitor. Measures statistics of the firewall
servers during the scenario.
Web Server Resource
Monitors. Measure
statistics of the Microsoft IIS, iPlanet (SNMP), and iPlanet/Netscape Web
servers during the scenario.
Web Application Server
Resource Monitors. Measure
statistics of the Ariba, iPlanet (NAS), Microsoft ASP, WebLogic (SNMP), and
WebSphere application servers during the scenario.
Database
Server Resource
Monitors. Measure
statistics of the SQL server, Oracle, and DB2 databases during
the scenario.
Streaming Media
Monitors. Measure
statistics of the RealPlayer and Media Player client during the scenario.
ERP/CRM Server Resource
Monitors. Measure
statistics of the SAP Portal, SAP CCMS, SAPGUI, Siebel Server Manager,
Siebel Web Server, and PeopleSoft (Tuxedo) servers during the scenario.
Java Performance Monitor. Measures statistics of Java 2
Platform, Enterprise Edition (J2EE) objects, and Java-based applications, using
J2EE machines.
J2EE & .NET
Diagnostics Monitors. Provide
information to trace, time, and troubleshoot individual transactions through
J2EE & .NET Web, application, and database servers.
Application Component Monitor. Measures statistics of the
Microsoft COM+ server during a scenario run.
Application Deployment
Solutions Monitor. Measures statistics of the
Citrix MetaFrame XP and 1.8 servers during a scenario run.
Middleware Performance
Monitors. Measure
statistics of the
Tuxedo and IBM WebSphere
MQ servers during a scenario run.
Infrastructure Resources Monitor. Measures statistics of the
network client data points during a scenario run.
The types of graphs comes under client
side monitoring:
1) Running vusers
2) Transaction Response Time
3) User Defined Data Points
4) Total Transaction / Sec
5) Hits per Second
6) Throughput
7) Error Statistics
2) Transaction Response Time
3) User Defined Data Points
4) Total Transaction / Sec
5) Hits per Second
6) Throughput
7) Error Statistics
The default number of graphs used in loadrunner are: 4
One can also view one, two, four, eight and at the maximum 16 graphs can be viewed.
One can also view one, two, four, eight and at the maximum 16 graphs can be viewed.
If one want to view more than
sixteen, it is not possible in loadrunner
Follow the below mentioned
steps to view the graphs
Select the Menu option View-> View Graphs -> Enter the number of graphs to be viewed
Select the Menu option View-> View Graphs -> Enter the number of graphs to be viewed
Follow the below mentioned steps to add the monitor graph
in load runner controller
1) Open the controller scecnario
2) Select the Run tab (in the bottom) of controller
3) View the graphs more than 8 (View -> View Graphs ->Enter number 8)
4) Drag the desired graph and drop into the graph area
5) Right Click on the graph and select Add measurements
6) Dialog pops up based on the counter you have chosen
7) Click on Add button
8) Add machine dialog box pops up
9) Enter the host name
10) Select the appropriate platform
11) Click OK
1) Open the controller scecnario
2) Select the Run tab (in the bottom) of controller
3) View the graphs more than 8 (View -> View Graphs ->Enter number 8)
4) Drag the desired graph and drop into the graph area
5) Right Click on the graph and select Add measurements
6) Dialog pops up based on the counter you have chosen
7) Click on Add button
8) Add machine dialog box pops up
9) Enter the host name
10) Select the appropriate platform
11) Click OK
To add the monitor graph follow the steps mentioned in 54. How do you add a monitor graph in
loadrunner controller?
The additional measures for a
windows based server can be added with the below mentioned
steps:
1) If there are any custom counters needs to be added click on Add button from measurements area (in the bottom)
2) If the server is a remote machine, it will pop up with server authentication dialog box.
3) Enter the credentials and click ok
4) If the server is s windows machine, it will show the windows resources dialog box
5) Select the object type
6) Select the counters for respective object
7) Click on add
8) Repeat the step 5 to 7 till all the counters gets added
9) Finally click close, then all the added counters can be seen from Resources measure on host
10) Click OK, then all the measures starts monitored on the controller
1) If there are any custom counters needs to be added click on Add button from measurements area (in the bottom)
2) If the server is a remote machine, it will pop up with server authentication dialog box.
3) Enter the credentials and click ok
4) If the server is s windows machine, it will show the windows resources dialog box
5) Select the object type
6) Select the counters for respective object
7) Click on add
8) Repeat the step 5 to 7 till all the counters gets added
9) Finally click close, then all the added counters can be seen from Resources measure on host
10) Click OK, then all the measures starts monitored on the controller
The default counters or
measures for
windows monitors given by
load runner are:
% Disk Time
(PhysicalDisk _Total)
Disk Time is the percentage of elapsed time that the selected disk drive is busy servicing read or write requests.
Disk Time is the percentage of elapsed time that the selected disk drive is busy servicing read or write requests.
% Processor Time
(Processor _Total)
% Processor Time is the percentage of time that the processor is executing a non-Idle thread. This counter was designed as a primary indicator of processor activity. It is calculated by measuring the time that the processor spends executing the thread of the Idle process in each sample interval, and subtracting that value from 100%. (Each processor has an Idle thread which consumes cycles when no other threads are ready to run). It can be viewed as the percentage of the sample interval spent doing useful work. This counter displays the average percentage of busy time observed during the sample interval. It is calculated by monitoring the time the service was inactive, and then subtracting that value from 100%.
% Processor Time is the percentage of time that the processor is executing a non-Idle thread. This counter was designed as a primary indicator of processor activity. It is calculated by measuring the time that the processor spends executing the thread of the Idle process in each sample interval, and subtracting that value from 100%. (Each processor has an Idle thread which consumes cycles when no other threads are ready to run). It can be viewed as the percentage of the sample interval spent doing useful work. This counter displays the average percentage of busy time observed during the sample interval. It is calculated by monitoring the time the service was inactive, and then subtracting that value from 100%.
Available MBytes
(Memory)
Available MBytes is the amount of physical memory available to processes running on the computer, in Megabytes, rather than bytes as reported in Memory\\Available Bytes. It is calculated by adding the amount of space on the Zeroed, Free, and Stand by memory lists. Free memory is ready for use; Zeroed memory are pages of memory filled with zeros to prevent later processes from seeing data used by a previous process; Standby memory is memory removed from a process' working set (its physical memory) on route to disk, but is still available to be recalled. This counter displays the last observed value only; it is not an average.
Available MBytes is the amount of physical memory available to processes running on the computer, in Megabytes, rather than bytes as reported in Memory\\Available Bytes. It is calculated by adding the amount of space on the Zeroed, Free, and Stand by memory lists. Free memory is ready for use; Zeroed memory are pages of memory filled with zeros to prevent later processes from seeing data used by a previous process; Standby memory is memory removed from a process' working set (its physical memory) on route to disk, but is still available to be recalled. This counter displays the last observed value only; it is not an average.
File
Data Operations/sec
(System)
File Data Operations per second is the rate that the computer is issuing Read and Write operations to file system devices. It does not include File Control Operations.
File Data Operations per second is the rate that the computer is issuing Read and Write operations to file system devices. It does not include File Control Operations.
Interrupts/sec
(Processor _Total)
Interrupts/sec is the average number of hardware interrupts the processor is receiving and servicing in each second. It does not include DPCs, which are counted separately. This value is an indirect indicator of the activity of devices that generate interrupts, such as the system clock, the mouse, disk drivers, data communication lines, network interface cards and other peripheral devices. These devices normally interrupt the processor when they have completed a task or require attention. Normal thread execution is suspended during interrupts. Most system clocks interrupt the processor every 10 milliseconds, creating a background of interrupt activity. This counter displays the difference between the values observed in the last two samples, divided by the duration of the sample interval.
Interrupts/sec is the average number of hardware interrupts the processor is receiving and servicing in each second. It does not include DPCs, which are counted separately. This value is an indirect indicator of the activity of devices that generate interrupts, such as the system clock, the mouse, disk drivers, data communication lines, network interface cards and other peripheral devices. These devices normally interrupt the processor when they have completed a task or require attention. Normal thread execution is suspended during interrupts. Most system clocks interrupt the processor every 10 milliseconds, creating a background of interrupt activity. This counter displays the difference between the values observed in the last two samples, divided by the duration of the sample interval.
Page Faults/sec (Memory)
Page Faults/sec is a count of the Page Faults in the processor. A page fault occurs when a process refers to a virtual memory page that is not in its Working Set in main memory. A Page Fault will not cause the page to be fetched from disk if that page is on the standby list, and hence already in main memory, or if it is in use by another process with whom the page is shared.
Page Faults/sec is a count of the Page Faults in the processor. A page fault occurs when a process refers to a virtual memory page that is not in its Working Set in main memory. A Page Fault will not cause the page to be fetched from disk if that page is on the standby list, and hence already in main memory, or if it is in use by another process with whom the page is shared.
Pages/sec (Memory)
Pages/sec is the number of pages read from the disk or written to the disk to resolve memory references to pages that were not in memory at the time of the reference. This is the sum of Pages Input/sec and Pages Output/sec. This counter includes paging traffic on behalf of the system Cache to access file data for applications. This value also includes the pages to/from non-cached mapped memory files. This is the primary counter to observe if you are concerned about excessive memory pressure (that is, thrashing), and the excessive paging that may result.
Pages/sec is the number of pages read from the disk or written to the disk to resolve memory references to pages that were not in memory at the time of the reference. This is the sum of Pages Input/sec and Pages Output/sec. This counter includes paging traffic on behalf of the system Cache to access file data for applications. This value also includes the pages to/from non-cached mapped memory files. This is the primary counter to observe if you are concerned about excessive memory pressure (that is, thrashing), and the excessive paging that may result.
Pool Nonpaged Bytes
(Memory)
Pool Nonpaged Bytes is the number of bytes in the Nonpaged Pool, a system memory area where space is acquired by operating system components as they accomplish their appointed tasks. Nonpaged Pool pages cannot be paged out to the paging file, but instead remain in main memory as long as they are allocated.
Pool Nonpaged Bytes is the number of bytes in the Nonpaged Pool, a system memory area where space is acquired by operating system components as they accomplish their appointed tasks. Nonpaged Pool pages cannot be paged out to the paging file, but instead remain in main memory as long as they are allocated.
Private Bytes (Process
_Total)
Private Bytes is the current number of bytes this process has allocated that cannot be shared with other processes.
Private Bytes is the current number of bytes this process has allocated that cannot be shared with other processes.
Processor Queue Length
(System)
Processor Queue Length is the instantaneous length of the processor queue in units of threads. This counter is always 0 unless you are also monitoring a thread counter. All processors use a single queue in which threads wait for processor cycles. This length does not include the threads that are currently executing. A sustained processor queue length greater than two generally indicates processor congestion. This is an instantaneous count, not an average over the time interval.
Processor Queue Length is the instantaneous length of the processor queue in units of threads. This counter is always 0 unless you are also monitoring a thread counter. All processors use a single queue in which threads wait for processor cycles. This length does not include the threads that are currently executing. A sustained processor queue length greater than two generally indicates processor congestion. This is an instantaneous count, not an average over the time interval.
Threads (Objects)
Threads is the number of threads in the computer at the time of data collection. Notice that this is an instantaneous count, not an average over the time interval. A thread is the basic executable entity that can execute instructions in a processor.
Threads is the number of threads in the computer at the time of data collection. Notice that this is an instantaneous count, not an average over the time interval. A thread is the basic executable entity that can execute instructions in a processor.
To add the monitor graph follow the steps mentioned in 54. How do you add a monitor graph in
loadrunner controller?
The additional measures for a
windows based server can be added with the below mentioned
steps:
1) If there are any custom counters needs to be added click on Add button from measurements area (in the bottom)
2) If the server is a remote machine, it will pop up with server authentication dialog box.
3) Enter the credentials and click ok
4) If the server is s windows machine, it will show the windows resources dialog box
5) Select the object type
6) Select the counters for respective object
7) Click on add
8) Repeat the step 5 to 7 till all the counters gets added
9) Finally click close, then all the added counters can be seen from Resources measure on host
10) Click OK, then all the measures starts monitored on the controller
1) If there are any custom counters needs to be added click on Add button from measurements area (in the bottom)
2) If the server is a remote machine, it will pop up with server authentication dialog box.
3) Enter the credentials and click ok
4) If the server is s windows machine, it will show the windows resources dialog box
5) Select the object type
6) Select the counters for respective object
7) Click on add
8) Repeat the step 5 to 7 till all the counters gets added
9) Finally click close, then all the added counters can be seen from Resources measure on host
10) Click OK, then all the measures starts monitored on the controller
Loadrunner diagnostics are used
for profiling the application server code and database server for
identifying the issues at the code or database level.
For example, if there is any
transaction is taking more than expected time. For getting the detailed
information on which of the servers are causing the problem for the high
response time, we use diagnostics.
Using diagnostics we can easily
pin point the problem on the application server, which API is causing the
problem.
Similarly we can also pin point
the problem on the database which of the SQL/SQLs is/are causing
the problem.
Using the multiple run time
settings we can set the common settings for multiple groups at a time.
The multiple run time settings
mode can be chosen with the below mentioned steps:
1) Open the controller scenario
2) Select the multiple groups on the controller
3) Click on the run time settings
4) The dialog box "Modifying Run-Time Settings for Multiple Scripts" opens
1) Open the controller scenario
2) Select the multiple groups on the controller
3) Click on the run time settings
4) The dialog box "Modifying Run-Time Settings for Multiple Scripts" opens
The Modifying Run-Time Settings
for Multiple Scripts will be invoked with the link:- 59. How do you enable multiple run time
settings mode?
Select
a method
for modifying run-time settings of multiple scripts:
Shared RTS. Opens one window containing all
of the run-time settings in blank mode. In this mode, you set only the options
that you would like to modify for all selected scripts. All other run-time
settings remain unchanged.
1) In shared RTS, all the fields will be with blank settings
2) Used for setting common settings
1) In shared RTS, all the fields will be with blank settings
2) Used for setting common settings
Individual RTS. Opens a separate window for
each selected script. In this mode, you modify each script's settings
individually.
1) Individual RTS, all the fields will be with default or initial settings
2) Used for giving individual run time settings for each script
1) Individual RTS, all the fields will be with default or initial settings
2) Used for giving individual run time settings for each script
