Known issues for load generators

This section describes troubleshooting and limitations for running Vusers on load generators machines.

Load generator not included with "All Generators"

When adding a Vuser group to a scenario in percentage mode, All Generators adds all the load generators apart from localhost.

Cause: By default, the load generator called "localhost" is defined as a Low Priority LG. Any load generator defined as a Low Priority LG is not included when clicking the All Generators button.

Resolution:

Do one of the following:

  • Manually add the host that was not included

  • Give "localhost" a different name, for example 127.0.0.1

  • Shut down Controller and edit <Installation directory>\Config\wlrun7.ini file. Under [General], add the following line:

    HostWithLowPriority=

Back to top

Overloading of CPU

If you receive a warning indicating that the load generator machine has reached 80% of the CPU resources, make sure that your load generator machine conforms to the recommended Support Matrix.

Back to top

Custom cipher

For communication between the various LoadRunner Professional components (such as Controller and Load Generator, or the MI Listener) you may need to specify your desired cipher. To do so, add a [SSLCipher] section to the config/m_agent_attribs.cfg file. Add the cipher name attribute using this syntax: "SSLCipherList=<cipher_string>". For more information, see the OpenSSL ciphers documentation.

Back to top

Virtual machines

LoadRunner Professional supports the latest versions of VMware ESX. However, running Vusers on virtual machines may adversely affect performance due to the sharing of physical resources.

Back to top

VB and C# projects

You cannot run VB and C# projects created with the Visual Studio add-ins on load generators with limited user permissions.

Back to top

Limited users

You cannot run LoadRunner Professional projects created in Visual Studio (VB and C#) on remote load generators if they were launched by a limited, non-admin user.

Back to top

ODBC scripts on Linux machines

When running ODBC scripts on RHEL 6, you may encounter the following replay error:

lrdb_open_connection: "SQLConnect", return-code=-1, native-error-code=0, SQLState=01000, SQLError=[unixODBC][Driver Manager]Can't open cursor lib 'libodbccr' : file not found"

Workaround: Create a libodbccr.so.1 soft link to libodbccr.so.2.0.0 using the following syntax:

n -s libodbccr.so.2.0.0 libodbccr.so.1

For details, see https://bugzilla.redhat.com/show_bug.cgi?id=719595.

Back to top

GUI Vusers

Windows Load Generator machines can only run one GUI Vuser at a time. To run multiple GUI Vusers in a load test, you need to open a terminal server session for each GUI Vuser.

Back to top

Non-English locales

Scripts containing Japanese symbols may generate errors during replay or fail during replay, when running on Linux load generators set to a Japanese locale.

Back to top

Automatic reconnection of load generators

If, during a load test, a load generator becomes disconnected from its network for a short period of time, LoadRunner Professional can automatically reconnect to the load generator and continue running the load test. However, you might experience the following issues when a load generator becomes disconnected:

  • If the load generator is disconnected while the script is being transferred from Controller to the load generator, the load generator does not reconnect automatically. We recommend restarting the Controller if the connection is lost during script transfer.
  • During the reconnection process, real-time data in Controller such as transactions and iterations might show lower than accurate values, because the values are not updated during reconnection. However, this data is not lost, and can be viewed in Analysis after the load test results are collated.

Back to top

Failure to add Linux load generators with IPv6

This section provides a solution if you are unable to add a Linux load generator machine using IPv6.

On Windows

Locate the <LRP_ installion_ folder>\launch_service\dat folder and edit the following files:

  • In the m_agent_attribs.cfg file, set the following flag in the FireWall section: FireWallServiceActive=1

  • In the br_lnch_server.cfg file, set the following flag in the Agent section: IPv6=1

On Linux

  • Locate the <LRP_ installion_ folder>/dat/br_lnch_server.cfg file, and set the following flag in the FireWall section: FireWallServiceActive=1

  • Locate the <LRP_ installion_ folder>/config/.mercury/m_agent_attribs_<machine name>.cfg\ file, and set the following flag in the Agent section: IPv6=1

Back to top