Configuring Run-Time Settings

The run-time settings define the way that the script runs. These settings are stored in the file default.cfg, located in the Vuser script directory. Run-time settings are applied to Vusers when you run a script using VuGen, the Controller.

For LoadRunner, the default run-time setting support the debugging environment of VuGen and the load testing environment of the Controller.
The default settings are:
Think Time. Off in VuGen and Replay as Recorded in the Controller.
Log. Standard in VuGen and off in the Controller.
Download non-HTML resources. Enabled in VuGen and the Controller.

For protocols that do NOT support multiple actions, such as WinSocket and Database (Oracle 2-tier, Sybase, MSSQL, and so on), the Iteration and Pacing options are both handled from the Pacing tab.

For the LoadRunner Controller: If you specify a scenario duration in the Scheduling settings, they override the Vuser iteration settings. This means that if the duration is set to five minutes (the default setting), the Vusers will continue to run as many iterations as required for five minutes, even if the run-time settings specify only one iteration.

If there is a Pacing node and not a Run Logic node under the General run-time settings, it is a single action protocol.
If the Run Logic node exists under the run-time settings, it is a multiple action protocol.

You can instruct a Vuser to repeat the Action section when you run the script. Each repetition is known as an iteration. The vuser_init and vuser_end sections of a Vuser script are not repeated when you run multiple iterations.

During execution, Vusers log information about themselves and their communication with the server. In a Windows environment, this information is stored in a file called output.txt in the script directory.
During development, enable logging so that you will have information about the replay. You should only disable logging after verifying that the script is functional.

You can program a Vuser script to send messages to an output log by using the lr_error_message and lr_output_message functions.

VuGen writes log messages that you can view in the Execution log. This option only affects automatic logging and log messages issued through lr_log_message. Messages sent manually, using lr_message, lr_output_message, and lr_error_message, are still issued.

If you choose to send messages only when errors occur, also known as JIT, (Just in Time) messaging, you can set an advanced option, indicating the size of the log cache.

If you set Error Handling to “Continue on error” in the General Run-Time Settings folder, error messages are still sent to the Output window.

If you modify the script’s Log Detail Level, the behavior of the lr_message, lr_output_message, and lr_log_message functions will not change—they will continue to send messages.

The degree to which VuGen logs events (Standard, Parameter substitution, and so forth) is also known as the message class. There are five message classes: Brief, Extended, Parameters, Result Data, and Full Trace.

The log cache stores raw data about the test execution, to make it available should an error occur. When the contents of the cache exceed the specified size, it deletes the oldest items. The default size is 1KB.

Vuser think time emulates the time that a real user waits between actions. For example, when a user receives data from a server, the user may wait several seconds to review the data before responding. This delay is known as the
think time. VuGen uses lr_think_time functions to record think time values into your Vuser scripts.

You can use the Think Time run-time settings to influence how the Vuser uses the recorded think time when you run the script.

LRD_ON_ERROR statements detect all types of errors—database related, invalid parameters, and so on. If you want the Vuser to terminate only when a database operation error occurs (Error Code 2009), you can set a function’s severity level. All functions that perform a database operation use severity levels, indicated by the function's final parameter, miDBErrorSeverity.

LRD_DB_ERROR_SEVERITY_ERROR-Terminate script execution upon database access errors.(default)- 0
LRD_DB_ERROR_SEVERITY_WARNING- Continue script execution upon database access errors, but issue a warning.- 1
When you enable Continue on Error, it overrides the “0” severity level; script execution continues even when database errors occur. However, if you disable Continue on Error, but you specify a severity level of “1”, script execution continues when database errors occur.

The primary advantage of a multithread environment is the ability to run more Vusers per load generator. Only threadsafe protocols should be run as threads.

The following protocols are not threadsafe: Sybase-Ctlib, Sybase-Dblib, Informix, Tuxedo, and PeopleSoft-Tuxedo.

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).

You can instruct LoadRunner to handle every step or action in a Vuser script as a transaction. This is called using automatic transactions. By default, automatic transactions per action are enabled.

VuGen runs Vuser scripts on Windows platforms only.

RunTime Data tab is not accessible after the test run, since it only displays data that changes during replay.

Transaction times may be increased when a Vuser generates a Results Summary report.

Vusers can generate Results Summary reports only when run from VuGen. When you run a script from the Controller, Vusers do not generate reports.

VuGen generates the results in VuGen report format—with a .qtp extension—and you view the results in the Virtual User Generator Report window.

Comments

  1. the concepts like run logic,pacing etc are missing, it would be better if you can explain the mentioned topics in these blog.

    ReplyDelete
  2. Thanks for the comment. I think Run Logic and Pacing were explained and mostly discussed in most of the forums that is why i did not touch it. I will prepare one on that.

    ReplyDelete

Post a Comment

Popular posts from this blog

Steps to Analyze AWR Report in Oracle

Vmstat Output explained

Verifications and Error Handling in LoadRunner *Web_reg_find and Web_reg_save_param*