Realistic load testing: Configuring population parameters and launch configurations

In Tricentis NeoLoad, a population is a group of virtual users that are configured (by type) to test an application. Each type can be set to have a different business or network behavior to reflect realistic load testing. For example, you can simulate 50% of your users to use a web-based browser carrying out a purchase, while another 50% of users browse via a 3G phone browser. Configuring groups of populations in this manner enables you to test your applications realistically using simulated conditions.

Why are changes to a testing population so significant? For starters, emulation for both bandwidth and hardware — along with identifying which user path to be tested — are configurable options which provide quantifiable metrics.

Let’s talk about two areas of the NeoLoad population component:

• Design -> Populations Tab
• Runtime -> Advanced Population Parameters

Important population parameters

Once you create a population, the selection of the three-dot […] button next to Browser is explained below.

Creating a NeoLoad population is simple. Here’s how:

1. Your Design -> Populations tab (lower left) allows for addition or removal of populations via a +/- sign.
2. Click the +, to add a population, and call this new population “Pop1.”
3. Next, we will add a 2nd population (referenced later), and call it “Pop2.”
4. Now, select “Pop1” on the left (you will see the following list of features that can be changed or modified: User Path, Percent, Browser, WAN Emulation, and Handle Cache options).
   • As mentioned above, we want to focus on the three-dot […] button next to Browser because there are some critical features inside that dialog which should be made known to all users of NeoLoad. We will cover the other features afterward.

Browser profiles picker

At the top, you can search for a specific browser (and phone type) to make selection easier.

Underneath the browser selection, you can see important features that provide the actions to disable/enable HTTP2. Although this is “on” by default, it is found that turning this to “off” can help solve certain problems as well as handle cookies (another setting which defaults to “on”). You can also set the number of parallel connections for HTTP1 (default is 6).

Tip: Should you encounter playback issues during realistic load testing, you might want to consider switching the “HTTP2 Disable” option to “off” altogether.

To address the other parameters, on the Populations tab, from top left to bottom right:

• User Path: Allows you to select which path is associated with this population.
• Percent: Because a population can include some user paths, it is necessary to specify the portions they represent in the population. When running a scenario with a given number of virtual users, this percentage defines the number of virtual users of each type to be used.
• WAN Emulation: The performance of an application is dependent upon the network. The WAN Emulation function enables the realistic recreation of existing IT or mobile network conditions with simulated bandwidth values, latency levels, and packet loss rates.
  • Note: You can also modify download and upload speed latency, packets dropped for the population.
• Handle Cache:
  • As recorded to reuse the configuration at the scenario recording
  • New user to have virtual users started with an empty cache
  • Returning user: The virtual user cache is up to date. The application does not return any response that contains information that is already cached.

Now, let’s switch gears and take a closer look at what choices can be modified during the launch of a test about population. If we click on the Runtime tab, we’ll find the Populations box again (this should contain both “Pop1” and “Pop2”). Let’s put a check into both populations, and while selecting the test scenario, click on the Advanced button at the bottom.

This brings up Advanced Population Parameters.

Here we have essential launch choices specific to the Start Policy for the selected population. Choose from:

• Immediately launching the population at the start of the test
• Delaying the launch of this population by X number of seconds
• Sequentially order the launch — the population after X other population has completed (in this case it would be “Pop2”)

Next, you can select how many users start when the population is chosen:

• Virtual users start
• Simultaneously: All virtual users begin at the same time
• Sequentially: All virtual users start over a period of X seconds

Finally, you can select the end policy for the population.

Stop policy

• Immediate: Stops all virtual users at the end of a test no matter where they are -> going to their end containers
• Delayed: Gives X seconds to finish their current iteration -> going to end container
• Indeterminate: Allows all virtual users to complete their current iteration before stopping the test and -> going to their end containers

Tip: Indeterminate may extend a test considerably if an iteration has a user path issue, so be aware that selecting this may cause tests to lag depending on the complexity of your user path workflows.

This blog was originally published in April 2018 and was refreshed in July 2021.