Pacing Loadrunner User Scenarios

Configuring the virtual user script with the number of virtual users

This article will describe the different options for pacing available within Loadrunner and outline how they can be used.  In the pervious blog  we calculated the necessary number of virtual users to produce the desired load.  The previous formula relied on the length of the user scenario.

How does the load generator execute the script?

The generator starts up the configured number virtual users (threads or processes). It can start them up gradually (e.g. 1 virtual user in every 5 seconds) or simultanously. This gradual start-up of virtual users is the called ramp-up. A gradual ramp-up generally more reflective of the actual behaviour of  the real users e.g. all site visitors do not check out the shopping cart sharply at 8 o’clock in the evening

Ramping up a user scenario gradually

Each virtual user executes the actions of the script in a defined order. This sequence is configured on the runtime settings/Run Logic pane.

Virtual User Generator's (VuGen) Run logic settings specified the sequence of script action execution

It is also possible to create block of actions. This makes it possible to repeat certain actions and also define the percentage certain actions are to be executed.

Virtual User Generator. Run Logic configuration with execution blocks
Run logic settings with blocks, number of iterations and percentages set

Besides ramp-up it is also possible to define when the load generator should start a new iteration of the script. Loadrunner offers three options for this:

  1. Start a new script iteration as soon as the previous iteration ends. This is the default option. The load generator starts repeating the script here without any adjustments. This means the Payday Loan generated load is heavily dependent on response times and think times. Our control over the projected load is simply lost. Moreover, this option can lead to a seriously distorted load test, which will not match the desired workload model.
  2. Start a new script iteration with delay after the previous iteration ends. The choice here is a fixed delay or a random period (specified with lower and upper bounds). This option represents a much more life-like load, however the transactions per second rate (TPS) still depends on the actual response time of the script.
  3. Start a new script iteration at fixed/random intervalls. This is the most regulated option of the three choices. Here Loadrunner will attempt to start every user iteration at a fixed pace, therefore the projected load is well controlled and easy to calculate with (see the previous article on determining the necessary number of virtual users depending on the runtime length of the user scenario ). My recommendation to use the Random option, where you specify a lower and upper bound into which the scenarios runtime length should comfortably fit. Specifying this random range introduces a random pattern into the load, which makes it more realistic.
Start iteration at random intervalls at the Pacing runtime settings.

But how do you  determine the right intervall? Let’s assume that our user scenario’s average runtime length is 5 seconds. Let’s round it up to e.g. 10 seconds, and choose an interval with this median, e.g. [8 sec; 12 sec].  By doing this the iteration will be started on average every 10 seconds. The 10 seconds value as a length of the iteration can be used when calculating the necessary number of virtual users.

Leave a Reply

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