LoadRunner – Runtime Settings – Miscellaneous

LoadRunner Runtime Settings - Miscellaneous

The ‘Miscellaneous’ tab under Runtime Settings of LoadRunner helps to configure the settings related to

  1. Error Handling
  2. Multi-threading
  3. Automatic Transaction
LoadRunner - Runtime Settings - Miscellaneous
Figure 01: LoadRunner – Runtime Settings – Miscellaneous Tab

Error Handling: This setting handles the errors during a performance test or while replaying the script. Error Handling section has three more options:

Error Handling
Figure 02: Error Handling Settings

1. Continue on error: This is a checkbox. If you checkmark this option then Vusers will be continuing the test even there are errors. By default this option is unchecked. The user will be terminated if unchecked it.

The use of ‘Continue on error’ setting depends on the requirement. Sometimes you need to keep it enable to list out the type and number of errors during the test.

Function: By using lr_continue_on_error function you can apply this setting on a portion of the script instead of the whole script. You need to enclose the requests that may be getting error in between lr_continue_on_error(1) and lr_continue_on_error(0).

Continue of error Code
Figure 03: lr_continue_on_error code

2. Fail open transactions on lr_error_message: If ‘Fail open transactions on lr_error_message’ is selected then lr_error_message function will fail the transaction and send the message. VuGen displays the message text of the lr_error_message function in the Execution log in red. Note that this function sends a message to the output even when logging is disabled in the run-time settings.

3. Generate snapshot on error: After enabling this option, LR generates a snapshot when an error occurs. You can see the snapshot by viewing the Vuser Log and double-clicking on the line at which the error occurred.

Multi-threading: The Controller uses a driver program (such as mdrv.exe or r3vuser.exe) to run the Vusers. If you run each Vuser as a process, then the same driver program is launched (and loaded) into the memory again and again for every instance of the Vuser. Alternatively, if you run each Vuser as a thread, the Controller launches only one instance of the driver program (such as mdrv.exe), for every 50 Vusers (by default).

LoadRunner - Runtime Settings - Miscellaneous - Multithreading
Figure 04: Multithreading

Get more information on “Run Vuser as Thread” vs “Run Vuser as Process”

Automatic Transactions: It has two options:

LoadRunner - Runtime Settings - Miscellaneous - Automatic Transactions
Figure 05: Automatic Transactions

1. Defined each action as a transaction: If you checkmark this option then LR treats each action in the script as a separate transaction for performance measurement which you can see in the Analysis tool while analysing the result.

2. Define each step as a transaction: Using this option you can make each step as a transaction. Majorly web_submit_data(), web_submit_form(), web_url(), etc. functions are treated as a transaction.

Some important things to be remembered for Miscellaneous setting:

  • This setting is available only for specific protocols.
  • It is not recommended enabling both the Continue on Error and Generate Snapshot on Error options in a load test environment. This configuration may adversely affect the Vusers’ performance.
  • The following protocols should not be run as threads: Sybase-Ctlib, Sybase-Dblib, Tuxedo, and PeopleSoft-Tuxedo. How to identify which protocol supports ‘Run Vuser as a Process’?
  • If you require the Vusers to generate breakdown data for diagnostics (J2EE) during the scenario run, do not use automatic transactions. Instead, manually define the beginning and end of each transaction.
  • You will need to check with your development team if the application is thread-safe or not. If it’s not thread-safe, then you may have to choose run Vuser as a process because running Vuser as a thread will not work with your application.
  • By default, LoadRunner configurations have 50 as the max limit on the number of threads which can run within a single process. Though you can increase this number, however, it’s good to keep in mind that by increasing this limit to some unreasonable number will make system/injectors unstable. So, it’s strongly recommended to keep it as the default unless the LoadRunner team recommends you to do so.

Leave a Reply

Your email address will not be published. Required fields are marked *