How-to configure vuser behavior in Vugen that affects time

Posted: April 21st, 2008 | Author: TnT Admin | Filed under: Concepts | Tags: , | 5 Comments »

In this article, we will walkthrough the settings that will enable your vuser (script) to perform in a certain behavior. We will start off with the configurations that affects time and the subsequent article in Vugen, we will be also touching on the configuration for time in Controller and settings that affects locality.

[1] Think Time

Think time is as recorded during the recording of the application. During the recording, you maybe entering values into the text fields, or browsing through your data sheet or maybe thinking of something (whatever…), all these will be recorded and generate as a LoadRunner API, lr_think_time.

In your Script-view, for example you should see it as lr_think_time(90) if you had used 90secs to perform a task such as entering values into an online form. To change the value, simply change the value in lr_think_time(90) to lr_think_time(60) which means you are changing the value frm 90secs to 60secs. This is the same in the Tree-view. That is to change the value for Think Time.

You can further manipulate how the Think Time will be replayed in the Run-Time Settings.

You can choose the following options to suit your needs.

    1. Ignore think time
    2. Replay think time as recorded
    3. Multiply recorded think time by
    4. Use random percentage of recorded think time

Ignore think time

Your script is going to run like a robot where there is no delay between each form submission. Not possible for a real human to do that which makes the load test unreal.

Replay think time as recorded

This setting will cause the script to replay as it is. It looks all good in Vugen at first but when you are in the Controller, it looks weird as all vusers will be replaying at the same amount of think time, which again, looked like cloned robots. If you have transactions created for the script, in the Controller graphs, all transactions will perform at the same speed.

Multiply recorded think time by

Straight-foward description; this setting multiplies the recorded value with the numeral provided, extending the time delay in the script.

Use random percentage of recorded think time

Personally, I like to use this option where the script will replay the percentage range of the recorded think time. With the recorded think time, I allow 50% – 150% deviation emulating the expert users (lower range:50%) and novice users (upper range:150%). I presumed the speed I’m working (recording) with the application is at an average user speed.

Limit think time to

This last option allows the script to replay the think time at a defined minimal limit.

[2] Pacing

Pacing is the interval between each iterations which defines the time the script waits between iterations of actions. Below is the screenshot of the Pacing options in the Runtime Settings launched from Vugen.(click on image to enlarge)

You can choose the following options to suit your needs.

    1. As soon as the previous iteration ends
    2. After the previous iteration ends with a fixed or random delay of ..
    3. At fixed/random intervals, every …

As soon as the previous iteration ends

The default setting in Vugen. The next iteration will start without any delay after the current iteration ends. The following illustrates the setting better.(click on image to enlarge)

After the previous iteration ends with a fixed or random delay of ...

This setting will start the next iteration after the current iteration ends and with the defined delay (setting) achieved. This interval can be either fixed or random and applies for all iterations. The following illustrates the setting better. (click on image to enlarge)

At fixed/random intervals, every …

This setting will start the next iteration based on the start of the previous iterations. For example you defined 30secs as the interval, the iteration completes in 12secs in the 30secs timeframe, then the next iteration will start after 18secs. Note, the scheduled iterations will only begin when the previous iteration is complete. The following illustrates the setting better.(click on image to enlarge)

[3] Action blocks

Action blocks are groups of actions within the vuser script. Actually you can think of it as two components. One, is the action which is defined in the script and two, the block that holds the actions. As mentioned earlier in previous article, Configuring Real User Behavior in LoadRunner – Time, the purpose of action blocks allowed the tester to define a modular action of the real user.

What can you do with the action blocks:

    1. The actions to be included in a block
    2. The sequence of the actions in a block
    3. The number of iterations that the block will run

Below illustrates the Run-time Settings for the Run Logic. (Click on the image to enlarge it).


Let’s discuss a little more on this action blocks. For the actions, actually you can’t do much with it except to choose it from the list of actions available in the script and then place it in your desired block. Most of the settings are on the block itself.

Note:
The “Run” is also consider a block with iterations of its own.

For the block, after you inserted one, you can provide the number of iterations for the block and include the actions that will be part of the block. Furthermore, you can define the block to perform either sequentially or randomly (via percentage parameter). This is all configurable at the block level, that’s to say, for each block, you can configure iterations, type of actions and sequence. Below illustrates the settings (click on the image to enlarge it).

Note:
Be careful when you delete a block, the actions in the block will also be removed!

[4] Iteration

What iteration does is to define the vusers to repeat a set of actions a specified number of times.

Previously mentioned in this article, iteration is configured on the block level. Take note that iteration is applicable to “Run” block (which is also applicable to blocks that are within the “Run” block). It is not applicable to “Init” and “End” block which is unlike insertion of actions in “Init” and “End” block that is applicable.

Note:
When the script is ported into Controller for load testing, the scenario scheduling settings will override the vuser iteration settings. This means that if the duration is set to the five minutes (default), the vusers will continue to run as many iterations as required until the five minute completes, even if the run-time settings in Vugen specifies one iteration only.

(Source: Vugen User Guide, Chapter 12, Configuring Run-Time Settings)

A good recommendation of using iteration other than for simulating an action performed multiple times is to ensure the parameter settings are working fine before proceeding with the scenario setup in the Controller.

Related Posts


5 Comments on “How-to configure vuser behavior in Vugen that affects time”

  1. 1 Dmitry Motevich said at 9:15 pm on December 2nd, 2008:

    Great explanation, Hwee Seong! Your schemes help to understand the principles of Pacing settings

  2. 2 Sridhar said at 6:46 pm on March 3rd, 2009:

    how can we identify concurrent vusers and simultanious users in loadrunner?

  3. 3 Sridhar said at 1:18 pm on March 17th, 2009:

    Hi
    what is the use of VBA in LoadRunner?

    if any one knows, plz explain…

  4. 4 Sridhar said at 1:21 pm on March 17th, 2009:

    how to emulate concurrent users and simultaneous users in LR?
    eg: if i want to emulate 100 concurrent users and 500 simultaneous users what are the settngs needs to be done in LoadRunner?

  5. 5 Mazar said at 2:23 am on April 15th, 2009:

    You have to use the Rendevouz option to achieve concurrency during the test, look for it in the user guide. thanks


Leave a Reply