Lr_exit (Lr_exit_action_and_continue, Lr_auto); Exit without any condition, and go directly to end action
Lr_exit (Lr_exit_main_iteration_and_continue, Lr_auto); Stop current action, and go to the next action
Lr_exit (Lr_exit_iteration_and_continue, Lr_auto); Stop current iteration, and go to the next iteration. If called from within a block iteration, only the block iteration would be exited, and not the global iteration
Lr_exit (Lr_exit_vuser_after_iteration, Lr_auto); Run until the end of the iteration and then exit
Lr_exit (Lr_exit_vuser_after_action, Lr_auto); Run until the end of the current action and then exit
--------------------------------------------------------------------------------------
About setting up
LoadRunner Script Runtime Settings57
by Stuart Moncrieff on October 15th, 2006
When running a training or mentoring session, people often ask what runtime settings they should use; As if there is a magical list of settings that'll always be correct for any testing situation. Obviously you select runtime settings that is appropriate for what is trying to achieve with your test, but the Funn Y thing is this there is actually a small list of settings this is usually appropriate for most situations. Read on ...
Whenever I am using a vuser type that allows multiple actions in a single script, I'll create a separate action for each Business process and put appropriate percentage weightings on each action. It is very unusual to has to do anything more complicated than this. I don ' t usually use the "sequential" option or create blocks unless I need to has fractional percentage weightings for a Business process–percentages must is integer values, so-to-run a business process 0.1% of the time you could create a BL Ock that runs 1% of the time, and put a 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 do by time or set to RU n indefinitely). Generally "number of iterations" is a used when running the script in Vugen.
- "As soon as the previous iteration ends" is used when running in Vugen or when loading/verifying data. Do not use the this for load testing
- I have never seen the ' after the previous iteration ends ' option. Why would 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 would tend to stay that's and continue to all hits the server at The same time.
- The ' at random intervals ' is definitely the ' to go '. Obviously for your users to create a certain number of orders per hour the iteration time must average to 3600/num Iterati ONS in an hour. The lower boundary value any bigger than the maximum time it takes to complete the business process, or you WI ll end up creating less transactions per hour than your intend to.
- Logging creates additional overhead on your load generators, and can create huge log files.
- I 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 W Hen an error occurs ". This gives a little to information than turning logging off entirely, and won ' t create any additional overhead while Eve Rything is running smoothly (and if the system isn't running smoothly you be going to need to stop the test and investig Ate anyway).
- Just like the pacing setting, I think that it's 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 your is debugging in Vugen or if you are loading/verifying data.
- This option is ignored by the most people. It is used to create a parameter with a given value without have to edit the script (as runtime settings can Overridd En in the Controller).
- In the screenshot I has created a parameter of ServerName with the address of the the test envioronment. If you were testing in more than one test environment at a time, this would make save some time.
- Continue On error was generally only going to be used if you had written code to does 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 as a real user because it'll create a Lot of Additional-very little benefit, but doing something-like writing some useful information to the LO GS and then calling Lr_exit (Lr_exit_action_and_continue, Lr_fail) can is useful.
- "Fail Open transactions on Lr_error_message" should always be ticked. If you are raising a error, you should fail the transaction step, which is performing.
- "Generate Snapshot On Error" is useful. If It is a web script, the any error messages should are added to your content check rules.
- Run your virtual user as a thread unless you had code that was not threadsafe or there was some other reason to run your VI Rtual users as a process. The overall memory footprint on your load generators would be higher if you run as a process.
- I never use the ' Define each action as a transaction ' option. If I want a transaction in my script I'll add it myself with Lr_start_transaction.
- I never use "Define each step as a transaction" either. If It is a Web script, I can use the transaction breakdown graph to get this information, otherwise I'll add the Transac tions myself.
- Not all vuser types has this option available.
- Most of the time my virtual users would use the maximum bandwidth.
- If I want to emulate users with bandwidth constraints, I'll do this in a separate scenario.
- Google Calculator is handy to calculate bitrates if your bitrate are not available from the Drop-down list e.g./" In bps "
All of the following settings is only apply to web-based scripts. Each vuser type would have the its own runtime setting options. It's important to know what they mean and how they would influence your test results before running any tests this you PLA N to report on.
- 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 with Firefox 1.5, you do not have the. Change the runtime settings For your the users to match this. All it changes are the string that's sent in the "user-agent" field of your HTTP requests. This is completely pointless unless your application have been written to serve different content to different browsers BAS Ed on the User-agent field.
- Todo
- Generally people won ' is using your Web applications through your proxy server, so it shouldn ' t is part of your test eith Er.
- If you start getting errors that is due a proxy server rather than the system under test, it'll just confuse the people Who has to fix the problem.
- A Proxy Server would also make ip-based load balancing ineffective.
- If It's an intranet application and everyone'll be using the application through the company's proxy, then the proxy ser Ver should is explicity declared to being in the scope for your load test. You should make sure so you had an identical proxy server for your test environment, or so you had permission to be Generating load on a piece of Production infrastructure.
- These settings was default values specified by Mercury, rather than being inherited from the Web browser that's installed On your workstation. Generally you won't need to change them, but being aware that they is here.
- Download filters is a quick-to-preventing your scripts from downloading content from certain URLs or hosts/domains.
- I generally use this feature if the Web application in the test environment contains third-party images used for Trackin G website usage (e.g. images from Webtrends or Red Sheriff etc).
- I think it was better to specify which hosts your script was allowed connect to, rather than which hosts your script can ' t C Onnect to (because it's easy to miss one accidentally, or the application could 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.
- I have the talked about Content Check rules before; I think that if you aren ' t using them already and then you're not getting the most out of the LoadRunner Feature-set.
About various exits
