Percentage

Because a Population can include a number of User Paths, it is necessary to specify the portions they represent in the Population.

In the Populations tab, for every Virtual User selected in the Content group box, it is necessary to set its representation percentage in the Percent field. 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. The percentage value may be set either by entering it in the text field or using the slider. It may be set within precision of 0.1%.

• Information: Where the sum of the percentages in each row does not equal 100%, the percentage displayed in the Content group box is highlighted in red. It is necessary to balance the Virtual Users.
  However, NeoLoad automatically adjusts the percentages before the test, taking into account the proportions initially defined. For example, a Population made up of 7% visitors, 2% buyers and 1% administrators is equivalent to a Population of 70% visitors, 20% buyers and 10% administrators.

Browser profile

The Browser dialog makes it possible to define a browser profile used by the selected User Path. It may prove relevant to use a specific browser profile for a load test when the content of the server response depends on the browser used.

The Available browser profiles list makes it possible to select one of the following profiles:

• Recorded one is the default option. It is the browser used when recording the scenario. As soon as a parameter is modified, it automatically switches to Customized.
• Customized is applied when one or more specific parameters are set on a listed profile.
• A pre-configured profile carries default values according to the simulated browser. The Search field above is useful to filter the profiles list. A pre-defined profile can serve as a frame to set a Customized one.

• Information: Additional pre-configured browsers can be specified in the C:\Program Files (x86)\NeoLoad 9.0\conf\pickers\browser_profiles folder. However, it is easier to configure a Customized profile in the Browser dialog when the need is specific.

When a browser profile is selected, the Parameters group box displays its default and additional parameters:

• HTTP/2: Checking this box enables the HTTP/2 protocol on the selected browser profile.

  SPDY is no longer supported and has been replaced by HTTP/2. The focus of HTTP/2 protocol is on performance; specifically, end-user perceived latency, network and server resource usage. One major goal is to allow the use of a single connection from browsers to a Web site. For more information about HTTP/2, see https://http2.github.io/.

• Handle cookies: Selecting the check box activates the ability for Virtual Users to handle cookies. Deactivating cookies helps check that the application can be used with a browser whose cookies management is deactivated, and force the server to use the URL rewriting facility to keep the session alive.
• HTTP/1 Parallel connections: This field makes it possible to set the number of HTTP1 connections which may be opened simultaneously on the remote server by one Virtual User.
• Accept encoding: The list allows selecting the encoding format for the request content. The supported formats are: "Gzip", "Deflate", "Brotli", "EXI", "BZip2", "LZMA", "XZ". Ticking the appropriate check box selects/unselects the format to be used.
  
  Warning: For POST requests, the only format supported is "gzip".
• User agent: In this field, the authenticating HTTP User Agent headers of the browser can be specified.

WAN emulation

The performance of an application is dependent on the network. The WAN Emulation function enables to realistically recreate the conditions of an existing IT or mobile network with simulated bandwidth values, latency levels, and packet loss rates.

A click on the picker button of the WAN Emulation field displays the WAN Emulation dialog box.

The WAN Emulation function is useful to simulate degraded network conditions with latency periods and packet loss percentages.

• Information: On Linux, the WAN Emulation requires a driver or module to be installed. For more information, see Install the WAN emulation On Linux.

In the WAN Emulation dialog box, the Available WAN Emulation profiles list makes it possible to select one of the following profiles:

• Unlimited is the default option. It is bandwidth, latency, and packet loss free, meaning that no WAN Emulation is applied. As soon as a parameter is modified, it automatically switches to Customized.
• Customized is applied when one or more specific parameters are set on an Unlimited profile or a pre-configured one.
• a pre-configured profile carries default real-world values according to the simulated protocol. The Search field above is useful to filter the profiles list. A pre-defined profile can serve as a frame to set a Customized one.

The values for the network conditions applicable in the tests are configured in the Parameters group box.

• The Signal strength drop-down list is reserved for mobile networks. The Good selection stands for the highest real uploading and downloading values in Mbps for the selected network type. The other Average and Poor options suggest signal measures (66% and 33% respectively). Custom values can be entered in the fields beneath according to the quality of the local mobile network.
• In the Upload and Download fields, custom bandwidth values can be specified in Kbps or Mbps.
• In the Upload latency and Download latency fields, custom latency values in ms can be entered or set with the field sliders. The values specified here are additional simulated latency measures: The IT architecture may generate its own latency, according to the location of the <productname> Controller, the <productname> Load Generators, and the application itself.
• In the Upload packets dropped and Download packets dropped fields, custom packet loss percentage values can be entered or set with the field sliders.

A click on the OK button closes the WAN Emulation box.

• Warning: The WAN Emulation parameters are left aside when a connection error occurs. When a Load Generator generates NL-NETWORK-* errors, additional latency values are ignored when the connection is lost between the Load Generator and the server.

• Tip: Other Virtual Users and Populations can be defined to simulate different types of network with specific WAN Emulation parameters.

The WAN Emulation parameters are enforced on the Load Generators before starting a test. In the Runtime section, Load Generators with a crossed mobile phone icon are not WAN emulated. When the test is started, the Execution Sanity Check wizard displays a warning message about it, as described in Check the test sanity before execution. Still, the test can be run, but the latency and the packet loss parameters are ignored.

• Note: For more information about WAN emulated Load Generators, see Zones and Load Generator hosts.

Measure network characteristics from a computer

The easiest way to measure the latency and packet loss rate between a computer and a server is to use the ping command with enough requests to get a reliable number of packets lost. For example ping –n 100 www.myserver.com to send 100 packets.

When each packet has been sent, the program displays the statistics for response times (latency) and the number of packets sent, received and lost.

The latency given is a round-trip latency. It is necessary to divide the measure by two to get a sound approximation of upload and download latency.

Measure network characteristics from a mobile device

A number of free mobile applications are available on mobile stores to send the same Ping commands as it can be done on computers. For example, Free Ping is one application on iOS.

These programs displays the statistics for response times (latency) and the number of packets sent, received and lost.

The latency given is a round-trip latency. It is necessary to divide the measure by two to get a sound approximation of upload and download latency.

Cache Management

Initializing the cache when Virtual Users are started can be defined in three behaviors:

• As recorded: The Virtual Users cache behavior is the same as in the scenario recording.
• New user: The Virtual Users are started with an empty cache to simulate users who have never visited the application.
• Returning user: The Virtual User cache is up to date. The application does not return any response which contains information that is already cached.

• Information: The cache management policy is applicable when a Virtual User is started. To fine-tune the cache between two iterations of a Virtual User, see Actions Container.