Troubleshooting

This topic lists troubleshooting issues and possible solutions, by application area.

Monitoring troubleshooting

The following tables list troubleshooting issues for monitoring.

General

Problem Possible solution

Problem	Possible solution
I am running/ran a load test, but my monitor is not displaying any measurements	Check if your monitor or monitoring tool is up and running and that OpenText Core Performance Engineering is connected to it.
I cannot monitor CPU usage on my application.	Verify that the `systat package` is deployed on the monitored application. To install the package, run the following command: `apt-get install sysstat`

I am running/ran a load test, but my monitor is not displaying any measurements

Check if your monitor or monitoring tool is up and running and that OpenText Core Performance Engineering is connected to it.

I cannot monitor CPU usage on my application.

Verify that the systat package is deployed on the monitored application.

To install the package, run the following command:

apt-get install sysstat

SiteScope

Problem	Possible solution
I enabled SiteScope data integration but I am not receiving any SiteScope data on my SiteScope on-premises monitor.	If you selected the Disable integration checkbox in the SiteScope configuration, but the agent continues to behave as it did before you made the change, restart the SiteScope service.
I deactivated SiteScope data integration but I am still receiving SiteScope data on my SiteScope on-premises monitor.	If you cleared the Disable integration checkbox in the SiteScope configuration, but the agent continues to behave as it did before you made the change, restart the SiteScope service.
The SiteScope on-premises monitor is displaying a monitor that I didn't select.	Stop the load test and reset the SiteScope agent and the SiteScope service.
SiteScope was unable to send data to the OpenText Core Performance Engineering agent.	Check the data integration log file generated under `SiteScope\log` folder.

Vusers

The following table lists troubleshooting issues for Vusers.

Error number	Problem	Possible solution
-1008	OpenText Core Performance Engineering uses a basic tolerance policy when provisioning Vusers before a test run. This policy instructs OpenText Core Performance Engineering to start a test when 95% of the scheduled Vusers have been provisioned, even if 5% of the Vusers were not. In most cases, testers do not want to fail a test if a small percentage of the Vusers were not provisioned. If less than 95% of the Vusers are provisioned, the test fails with system error -1008 after the timeout interval.	To change the default tolerance, for example to require 100% of the Vusers to be provisioned, or to learn more about the tolerance policy, submit a service request. For details on using the early start run capability which enables you to start a test as soon as the minimum threshold has been reached, see Enable early test start.
-1011	Vusers failed to initialize and the test was stopped. This may be caused by missing dependencies. By default, Web scripts are run on Linux machines, on which file names are case sensitive.	When you run a script that uses parameters on a Linux machine, ensure that: all the .dat files referenced in the .prm file are located in the script's root folder. the .dat file names used in the .prm file are identical to the actual file name.

Error number

Problem

Possible solution

-1008

OpenText Core Performance Engineering uses a basic tolerance policy when provisioning Vusers before a test run. This policy instructs OpenText Core Performance Engineering to start a test when 95% of the scheduled Vusers have been provisioned, even if 5% of the Vusers were not. In most cases, testers do not want to fail a test if a small percentage of the Vusers were not provisioned.

If less than 95% of the Vusers are provisioned, the test fails with system error -1008 after the timeout interval.

To change the default tolerance, for example to require 100% of the Vusers to be provisioned, or to learn more about the tolerance policy, submit a service request.

For details on using the early start run capability which enables you to start a test as soon as the minimum threshold has been reached, see Enable early test start.

-1011

Vusers failed to initialize and the test was stopped.

This may be caused by missing dependencies. By default, Web scripts are run on Linux machines, on which file names are case sensitive.

When you run a script that uses parameters on a Linux machine, ensure that:

all the .dat files referenced in the .prm file are located in the script's root folder.
the .dat file names used in the .prm file are identical to the actual file name.

LG alerts

If your load generators exceed their capacities, OpenText Core Performance Engineering issues alerts.

LG alerts are primarily triggered when there are not enough machine resources, such as CPU or memory. The alerts may be an indication that one or more of the LGs generated a value above the threshold values measured by OpenText Core Performance Engineering.

To prevent the alerts, your two primary areas of focus should be:

Load generator fine-tuning
Test configuration optimization

Load generator fine-tuning

This section describes best practices for fine-tuning your load generators (LGs). The fine-tuning can help you avoid LG alerts by reducing the maximum number of Vusers per LG for the specific protocol that you are running, on both on-premises load generators (OPLGs) and cloud load generators (CLGs).

For OPLGs, you can manually adjust the number of Vusers per protocol. For details, see Add and edit on-premises load generators. If the alerts persist, you can manually add more OPLGs.
On CLGs, to isolate the issue for a specific script, run the test using a single cloud region, and run it with the maximum number of Vusers per CLG that are set for the script's protocol. For example, if you want to troubleshoot a Web HTTP script whose default maximum Vusers per CLG is 2,500, try to run the script from a single location with 2,500 Vusers. If you encounter LG alerts, then rerun the test with less Vusers, for example 1,500. Continue in this manner until you no longer encounter alerts. This way, you can determine the ideal number of Vusers per CLG for the script's protocol.

To enable the option to set Vuser limits, submit a service request. If you change the number of maximum Vusers per CLG, it may affect the VU/VUH license consumption ratio, so be sure to review the service description before your request has been implemented. For details, see Set Vuser limits.

Test configuration optimization

In general, alerts indicate that the CPU and/or memory usage on the LG exceeds the system health threshold. Your test's performance and results might be impacted by the way the test is configured.

As a best practice, if your test has multiple scripts, try to isolate the scripts causing the load generator alerts and focus on optimizing the relevant script.

Instead of expanding the infrastructure as described above, try the following best practices to optimize your test configuration:

Increase the pacing in your script. Go to Load test > Load profile tab > Runtime settings > Pacing and increase the pacing between iterations.
If the alerts occur primarily during ramp up time, try to slow down the ramp up schedule. Go to Load test > Load profile tab and set a longer Ramp up time for your script.
Check if the application under test is using HTTP/2. HTTP/2 consumes a lot of client resources, which may be the cause of the alert. To deactivate HTTP/2, go to Load test > Load profile tab> Runtime settings > Preferences and deactivate HTTP/2.
Deactivate logs or set them to errors only in the script's runtime settings. Go to Load test > Load profile tab > Runtime settings > Log and deactivate logs or set them to errors only.
Use Browser Cache simulation in when your use case permits this (for example, when a new user is not needed for each iteration). Go to Load test > Load profile tab Runtime settings > Browser Emulation and enable Simulate browser cache.

Script optimization

Another way to handle LG alerts is to modify your script. The following are some of the best practices:

Add think time between transactions.
Avoid parsing all HTML content-type. In VuGen, go to Runtime settings > Preferences > General and set Parse HTML content-type to TEXT or HTML (do not set to ANY).
Optimize parsing, decoding, correlations and text searches:
1. Avoid decoding when it is not necessary. Decoding is used mainly to find correlations. For requests where correlations or texts are not being searched, we recommended to deactivate decoding using one of the following options:
  1. For VuGen versions earlier than 12.63. Add web_set_option("DecodeContent", "No", LAST ); at the beginning of the script and turn it on before, and off after, a request that requires decoding.
    
    When a request that requires decoding is in an extrares argument (for example, a JS file), we recommend removing it from the extrares and adding a separate web_url call so that only this file is decoded.
  2. For VuGen versions 12.63 and later. A new web_set_option flag was added called DecodeContentForResources and with a default setting of No. This setting can be used in the same way as the DecodeContent flag described above.
  For more details, refer to the VuGen Function Reference guide.
2. If you know that a correlation is returned in the HTML itself and not in the resources, we suggest adding Search=Noresource in the web_reg_save_param and web_reg_find calls. If not set, the default search setting is All.
3. Use more precise filtering, such as URL, for search correlations. For example:
```
SEARCH_FILTERS,
"Scope=Body",
"RequestUrl=*/myurl*",
```
4. Where possible (when no correlations or text searches are needed), set requests as resources ("Resource=1",).
Do not use HTML mode when browser emulation is not required (for example, a JSON response). Instead, use HTTP mode.

If you still receive load generator alerts after having optimized your tests and scripts, submit a service request.

On-premises load generator troubleshooting

For details, see Troubleshooting OPLGs.

Agent troubleshooting

The following table lists troubleshooting issues for agents.

Problem	Possible solution
An error is displayed when installing an on-premises load generator indicating that there is not enough disk space, even though there is.	Possible solution 1: Try restarting the machine and running the on-premises load generator installation again. Possible solution 2: Extract the downloaded SetupOneLG.zip file. This extracts the SetupOneLG.exe file to a local folder. Using 7zip, extract the SetupOneLG.exe file (its archived .exe). This creates a folder containing the setup.exe file. Run setup.exe.
Running multiple agents on the same machine is not supported and may result in failed tests.	If you experience issues when running multiple agents on the same host, try running a single agent on each host.

Problem

Possible solution

An error is displayed when installing an on-premises load generator indicating that there is not enough disk space, even though there is.

Possible solution 1:

Try restarting the machine and running the on-premises load generator installation again.

Possible solution 2:

Extract the downloaded SetupOneLG.zip file. This extracts the SetupOneLG.exe file to a local folder.
Using 7zip, extract the SetupOneLG.exe file (its archived .exe). This creates a folder containing the setup.exe file.
Run setup.exe.

Running multiple agents on the same machine is not supported and may result in failed tests.

If you experience issues when running multiple agents on the same host, try running a single agent on each host.

Test troubleshooting

The following table lists troubleshooting issues for tests.

Problem Possible solution

Problem	Possible solution
A test result is marked as archived and cannot be accessed.	By default, results that are older than three months are archived, except for older results that were set as a benchmark. To request retrieval of archived results, submit a service request.
My Vusers report out of memory errors so I want to run the Vusers as a process.	To request enabling Vusers to run as a process, submit a service request.
A test generates SSL errors.	As of LoadRunner Cloud 2023.03, the cloud and on-premises load generators (v2023.03) provided with LoadRunner Cloud were updated to support OpenSSL version 3.0. However, older LoadRunner versions use OpenSSL 1.1.1q which is planned to reach end of support in September 2023. OpenSSL 3.0 is FIPS 140-2 compliant and introduces an enhanced security policy, which by default, might deny non-compliant SSL connections. As a result, performance tests of an application under test (AUT) that is incompatible with the security policy enforced by OpenSSL 3.0 might fail. If a load test fails with SSL errors resulting from the OpenSSL 3.0 security policy, we highly recommend updating the AUT to align with the updated security policy. OpenText Core Performance Engineering provides an option to modify certain OpenSSL 3.0 settings to ignore certain errors. While such configurations can eliminate the above-mentioned test failure, for security reasons, they are not recommended as a permanent solution. Instead, we recommend fixing the AUT to support the updated OpenSSL 3.0 security policy, and then revert to the default OpenSSL settings. Known SSL errors that impact performance tests: The following are known SSL errors that might impact performance tests, and the OpenSSL 3.0 settings that can be modified to ignore the errors: ‘error:0A000126:SSL routines::unexpected eof while reading’. Modify the `SSL_OP_IGNORE_UNEXPECTED_EOF` setting to ignore this error. ‘error:0A000152:SSL routines::unsafe legacy renegotiation’. Modify the `SSL_OP_LEGACY_SERVER_CONNECT` setting to ignore this error. To modify the settings: Open the script's default.cfg file in a text editor. In the WEB section, add `OpenSSL3CompatibleConnection=1`. For example: Note: For an RDP protocol script, add `OpenSSL3CompatibleConnection=1` to the RDP section. Save and close the file. Create a zip of the script, and then reload it to OpenText Core Performance Engineering.

A test result is marked as archived and cannot be accessed.

By default, results that are older than three months are archived, except for older results that were set as a benchmark. To request retrieval of archived results, submit a service request.

My Vusers report out of memory errors so I want to run the Vusers as a process. To request enabling Vusers to run as a process, submit a service request.

A test generates SSL errors.

As of LoadRunner Cloud 2023.03, the cloud and on-premises load generators (v2023.03) provided with LoadRunner Cloud were updated to support OpenSSL version 3.0. However, older LoadRunner versions use OpenSSL 1.1.1q which is planned to reach end of support in September 2023.

OpenSSL 3.0 is FIPS 140-2 compliant and introduces an enhanced security policy, which by default, might deny non-compliant SSL connections. As a result, performance tests of an application under test (AUT) that is incompatible with the security policy enforced by OpenSSL 3.0 might fail. If a load test fails with SSL errors resulting from the OpenSSL 3.0 security policy, we highly recommend updating the AUT to align with the updated security policy.

OpenText Core Performance Engineering provides an option to modify certain OpenSSL 3.0 settings to ignore certain errors. While such configurations can eliminate the above-mentioned test failure, for security reasons, they are not recommended as a permanent solution. Instead, we recommend fixing the AUT to support the updated OpenSSL 3.0 security policy, and then revert to the default OpenSSL settings.

Known SSL errors that impact performance tests:

The following are known SSL errors that might impact performance tests, and the OpenSSL 3.0 settings that can be modified to ignore the errors:

‘error:0A000126:SSL routines::unexpected eof while reading’. Modify the SSL_OP_IGNORE_UNEXPECTED_EOF setting to ignore this error.
‘error:0A000152:SSL routines::unsafe legacy renegotiation’. Modify the SSL_OP_LEGACY_SERVER_CONNECT setting to ignore this error.

To modify the settings:

Open the script's default.cfg file in a text editor.
In the WEB section, add OpenSSL3CompatibleConnection=1. For example:

Note: For an RDP protocol script, add OpenSSL3CompatibleConnection=1 to the RDP section.

Save and close the file.
Create a zip of the script, and then reload it to OpenText Core Performance Engineering.

Report troubleshooting

Problem	Possible solution
When applying a report template to a new test run in which the script has been replaced (and the script contains different transactions), transaction data from the original test used to build the template is copied into the results.	Possible solution 1: Create a new template for the report. Possible solution 2: Update the existing template. For details, see Update template with transaction changes.

Problem

Possible solution

When applying a report template to a new test run in which the script has been replaced (and the script contains different transactions), transaction data from the original test used to build the template is copied into the results.

Possible solution 1:

Create a new template for the report.

Possible solution 2:

Update the existing template. For details, see Update template with transaction changes.

Log troubleshooting

The following table lists troubleshooting issues for logs.

Problem	Possible solution
Performance issues when running a load test.	Check to see if Extended Logging is enabled. After the initial debugging run, extended logging is not recommended for a load test.

Help Center troubleshooting

The following table lists troubleshooting issues for the Help Center.

Problem	Possible solution
Saved links to help pages from previous versions of the Help Center result in a 404 (page not found) error.	From the 404 page, click Home Page to access the Home page of the current Help Center. Replace the version number in the saved link with Latest. For example, change the URL: https://admhelp.microfocus.com/lrc/en/2021.01/Content/Resources/_TopNav/_TopNav_Home.htm to https://admhelp.microfocus.com/lrc/en/Latest/Content/Resources/_TopNav/_TopNav_Home.htm
When using the Japanese version of the OpenText Core Performance Engineering Help Center, the search functionality does not support Japanese characters.	Enter search strings in English. Results are shown in English, but the links open the relevant Japanese help pages.