In general load runner runtime settings plays a crucial role
in Vugen scripting and scenario running.This is the heart of the Load
runner.The run time settings are
General
- Run
Logic
- Pacing
- Log
- Think
Time
- Additional
attributes
- Miscellaneous
Network
Browser
Internet Protocol
- Proxy
- preferences
- download
filters
- Content
check
Data Format Extension
General
Run Logic
Whenever we are using a Vuser type that allows multiple actions in a single
script, we will create a separate action for each business process and put
appropriate percentage weightings on each action. We don’t usually use the “sequential”
option or create blocks unless I need to have fractional percentage weightings
for a business process.
Percentages must be integer values, so to run a business process 0.1% of the
time you could create a block that runs 1% of the time, and put an action in
the block that runs 10% of the time.
It’s also rare to set a script in a scenario to run for a specified number of
iterations (mostly done by time or set to run indefinitely). Generally “number
of iterations” is only used when running the script in VuGen.
Pacing :
“As soon as the previous iteration ends” is used when running in VuGen or when
loading/verifying data. Do not use this for load testing
We have never seen the point of the “After the previous iteration ends” option.
Why would you want to run an unknown number of transactions per hour against
the system?
Don’t use the “At fixed intervals”. If something causes your users to become
“in step”, they will tend to stay that way and continue to all hit the server
at the same time.
“At random intervals” is definitely the way to go. Obviously for your users to
create a certain number of orders per hour the iteration time must average to
3600/num iterations in an hour. Do not make the lower boundary value any bigger
than the maximum time it takes to complete the business process, or you will
end up creating less transactions per hour than you intend to.
you can check how to calculate pacing according to the requirement
from this blog also.
Log :
Enable logging:once you verify that your script is
functional,disable logging to conserve resources.
Logging creates additional overhead on your load generators, and can create
huge log files.
Log absolutely everything when debugging in VuGen.
When running the script as part of a scenario, We leave extended logging on but
change the logging to “Send messages only when an error occurs”. This
gives a little more information than turning logging off entirely, and won’t
create any additional overhead while everything is running smoothly (and if the
system is not running smoothly you are going to need to stop the test and
investigate anyway).
Standard log:sends a subset of functions and messages sent during script
execution to a log.The subset depends on the Vuser type.
Think Time:
Just like the pacing setting, We think that it is a good idea to put some
randomness in your think times.
We use a random percentage of 50-150% of recorded think times.
Use “Ignore think time” if you are debugging in VuGen or if you are
loading/verifying data.
Additional attributes :
This option is ignored by most people. It is used to create a parameter with a
given value without having to edit the script (as runtime settings can be
overridden in the Controller).
In the screen shot we have created a parameter of Server Name with the address of
the test environment. If you were testing in more than one test environment at
a time, this would make save some time.
Miscellaneous :
Continue on error is generally only going to be used if you have written code
to do something when you encounter an error. Usually the default behaviour of
ending the current iteration and then starting the next one is sufficient). We don’t advise anyone to try to write a script that handles errors in the same
way as a real user because it will create a lot of additional work for very
little benefit, but doing something simple like writing some useful information
to the logs and then calling lr_exit(LR_EXIT_ACTION_AND_CONTINUE , LR_FAIL) can
be useful.
“Fail open transactions on lr_error_message” should always be ticked. If you
are raising an error, you should fail the transaction step that you are
performing.
“Generate snapshot on error” is useful. If it is a web script, any error
messages should be added to your content check rules.
Run your virtual user as a thread unless you have code that is not thread safe
or there is some other reason to run your virtual users as a process. The
overall memory footprint on your load generators will be higher if you run as a
process.
We never use the “Define each action as a transaction” option. If we want a
transaction in our script we will add it myself with lr_start_transaction.
We never use “Define each step as a transaction” either. If it is a web script, we can use the transaction breakdown graph to get this information, otherwise we will add the transactions ourself.
Network :
Not all vuser types have this option available.
Most of the time my virtual users will use the maximum bandwidth.
If we want to emulate users with bandwidth constraints, we will do this in a
separate scenario.
Google calculator is handy to calculate bitrates if your bitrate is not
available from the drop-down list e.g./ “256 Kbps in bps”
All of the following settings only apply to web-based scripts. Each vuser type
will have its own runtime setting options. It is important to know what they
mean and how they will influence your
test results before running any tests that you plan to report on.
Browser
Browser Emulation:
Some people get confused by the User-Agent (browser to be emulated) setting. If
90% of your users use Internet Explorer 6.0 and the rest use Firefox 1.5, you
don’t have to change the runtime settings for your users to match this. All it
changes is the string that is sent in the “User-Agent” field of your HTTP
requests. This is completely pointless unless your application has been written
to serve different content to different browsers based on the User-Agent
field.
Internet Protocol:
Proxy :
Generally people won’t be using your web applications through your proxy
server, so it shouldn't be part of your test either.
If you start getting errors that are due a proxy server rather than the system
under test, it will just confuse the people who have to fix the problem.
A proxy server will also make IP-based load balancing ineffective.
If it’s an intranet application and everyone will be using the application
through the company’s proxy, then the proxy server should be explicity declared
to be in scope for your load test. You should make sure that you have an
identical proxy server for your test environment, or that you have permission
to be generating load on a piece of Production infrastructure.
Preferences :
These settings are default values specified by HP, rather than being inherited
from the web browser that is installed on your workstation. Generally you will
not need to change them, but be aware that they are here.
Download Filters:
Download filters are a quick way of preventing your scripts from downloading
content from certain URLs or hosts/domains.
We generally use this feature when the web application in the test environment
contains third-party images used for tracking website usage (e.g. images from
Webtrends or Red Sheriff etc). We think it is better to specify which hosts your script is allowed connect to,
rather than which hosts your script can’t connect to (because it’s easy to miss
one accidentally, or the application may change and refer to a new third-party
domain).
Use web_add_auto_filter if you want to specify this in your script rather than
your runtime settings.
Data Format Extension:
Configuration :
A LoadRunner feature that has made my life a lot easier has been ContentCheck
rules, which are available in the script runtime settings. If you are using a
web-based vuser type, you can configure your Load Runner script to search
through all returned pages for strings that match known error messages.
Using web_reg_find functions is fine, but when you get an error LoadRunner
reports it as “failed to find text” instead of something more
descriptive.
We will always create rules for any error messages we find during scripting and,
if we receive an error while running a scenario, we will add the error message
from the snapshot in the scenario results directory (the snapshot on error
feature is very useful).
If you prefer to have error message you are checking for in the script (where
you can add comments to them) instead of the runtime settings, you can use the
web_global_verification function instead. The only difference between the two
is the error message that LoadRunner will include in its log:
Action.c(737): Error -26368: “Text=A runtime error occurred” found for
web_global_verification (“ARuntimeErrorOccurred”) (count=1), Snapshot Info [MSH
0 21]
…compared to:
Action.c(737): Error -26372: ContentCheck Rule “ARuntimeErrorOccurred” in
Application “Webshop” triggered. Text “A runtime error occurred” matched
(count=1), Snapshot Info [MSH 0 21]
Source: http://easyloadrunner.blogspot.in
