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 :
The run time settings are :
General
General:
Run Logic
Whenever I am using a Vuser type that allows multiple actions in a single script, I will create a separate action for each business process and put appropriate percentage weightings on each action. It is very unusual to have,to do anything more complicated than this.
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
I 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” option. 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 of 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.
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 screenshot I have created a parameter of ServerName with the address of the test environment. If you were testing in more than one test environment at a time, this would save some time.
Miscellaneous :
Continue on error is 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. I 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 enable. 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.
“Define each step as a transaction”. If it is a web script, I can use the transaction breakdown graph to get this information, otherwise I will add the transactions myself.
Network :
Speed simulation :
Not for all vuser types this option is available.
Most of the time virtual users will use the maximum bandwidth.
If I want to emulate users with bandwidth constraints, I 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 applied to web-based scripts. Each vuser type will have its own runtime settings. 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 to 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 is 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.
Download Filters:
Download filters are a quick way of preventing your scripts from downloading content from certain URLs or hosts/domains.
I 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).
I 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.
Content Check : It is a global text verification point.
Extension of the rule/global verification point is .XML.
Data Format Extension:
Configuration :
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.
- Run Logic
- Pacing
- Log
- Think Time
- Additional attributes
- Miscellaneous
- Speed simulation
- Browser emulation
Internet Protocol
- Proxy
- preferences
- download filters
- Content check
Data Format Extension
- Configuration
General:
Run Logic
Whenever I am using a Vuser type that allows multiple actions in a single script, I will create a separate action for each business process and put appropriate percentage weightings on each action. It is very unusual to have,to do anything more complicated than this.
It is used 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
I 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” option. 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 of 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, I 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, I think that it is a good idea to put some randomness in your think times.
I 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 :
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, I 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, I think that it is a good idea to put some randomness in your think times.
I 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 screenshot I have created a parameter of ServerName with the address of the test environment. If you were testing in more than one test environment at a time, this would save some time.
Miscellaneous :
Continue on error is 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. I 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 enable. 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 Vuser as a Process
- Run Vuser as a Thread
By default Run vuser as a Thread will be enabled for web applications.
“Define each step as a transaction”. If it is a web script, I can use the transaction breakdown graph to get this information, otherwise I will add the transactions myself.
Network :
Speed simulation :
Not for all vuser types this option is available.
Most of the time virtual users will use the maximum bandwidth.
If I want to emulate users with bandwidth constraints, I 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 applied to web-based scripts. Each vuser type will have its own runtime settings. 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 to 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 is 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.
Download Filters:
Download filters are a quick way of preventing your scripts from downloading content from certain URLs or hosts/domains.
I 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).
I 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.
Content Check : It is a global text verification point.
Extension of the rule/global verification point is .XML.
Data Format Extension:
Configuration :
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.
No comments:
Post a Comment