Troubleshooting

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

Monitoring

The following tables list troubleshooting issues for monitoring.

General

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 LoadRunner Cloud 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 check box in the SiteScope configuration, but the agent continues to behave as it did before you made the change, restart the SiteScope service.

I disabled SiteScope data integration but I am still receiving SiteScope data on my SiteScope on-premises monitor.

If you cleared the Disable integration check box 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 LoadRunner Cloud agent. Check the data integration log file generated under SiteScope\log folder.

Dynatrace

Problem Possible solution
I am not receiving any data on my Dynatrace monitor. Check that Dynatrace is receiving data from your AUT. If it is not, then the issue is with your AUT.

Back to top

LG fine-tuning

This section describes best practices for fine-tuning your load generators (LGs). The fine-tuning can help you avoid LG alerts, for both on-premises load generators (OPLGs) and cloud load generators (CLGs).

To fine-tune your load generators, you can:

  • fine-tune your infrastructure

  • optimize your test or script configuration

Fine-tune your infrastructure

If your load generators exceed their capacities, LoadRunner Cloud will issues alerts. Alerts are primarily triggered when there are not enough machine resources, such as CPU or memory. They may also be an indication that one or more of the LGs generated a value above the threshold values measured by LoadRunner Cloud.

To prevent the alerts, your first objective should be to reduce the maximum number of Vusers per LG for the specific protocol that you are running, for both OPLGs and CLGs:

  • For OPLGs, you can manually adjust the number of Vusers per protocol. For details, see Add on-premises load generator assets. If the alerts persist, you can manually add more OPLGs.

  • On CLGs, to isolate the issue for a specific script, execute 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 reduce the maximum number of Vusers per LG for CLGs, you need to open a support ticket. Your ticket should include a request to reduce the maximum number of Vusers per CLG, for a specific protocol in a your project. Once this change is made, all future tests in this project using this protocol will use this configuration. If you change the number of maximum Vusers per CLG, it may affect the VU/VUH license ratio, so be sure to review the service description after your request has been implemented. If necessary, you can also request additional load generators in order to reduce the maximum number of Vusers per load generator.

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 that are causing the load generator alerts and then focus on optimizing the relevant script.

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

  1. Increase the pacing in your script. Navigate to Load test > Scripts tab > Runtime settings > Pacing and increase the pacing between iterations.

  2. If the alerts occur primarily during ramp up time, try to slow down the ramp up schedule. Navigate to Load test > Scripts tab and set a longer Ramp up time for your script.

  3. 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 disable HTTP/2, navigate to Load test > Scripts tab> Runtime settings > Preferences and disable HTTP/2.

  4. Disable logs or set them to errors only in the script's runtime settings. Navigate to Load test > Scripts tab > Runtime settings > Log and disable logs or set them to errors only.

  5. Use Browser Cache simulation in when your use case permits this (for example, when a new user is not needed for each iteration). Navigate to Load test > Scripts 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:

  1. Add think time between transactions.

  2. Avoid parsing all HTML content-type. In VuGen, navigate to Runtime settings > Preferences > General and set Parse HTML content-type to TEXT or HTML (do not set to ANY).

  3. 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 strongly recommended to disable 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 will be 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, see web_set_option.

    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",).
  4. 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, open a support ticket for additional assistance.

Back to top

Agents

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:

  1. Extract the downloaded SetupOneLG.zip file. This extracts the SetupOneLG.exe file to a local folder.

  2. Using 7zip, extract the SetupOneLG.exe file (its archived .exe). This creates a folder containing the setup.exe file.

  3. 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.

Back to top

Tests

The following table lists troubleshooting issues for tests.

Problem Possible solution

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

By default, results that are older than 18 months are archived. To request retrieval of archived results, open a support ticket.

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, open a support ticket.

Back to top

Logs

The following table lists troubleshooting issues for logs.

Problem Possible solution
General

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.

Back to top

Help Center

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

Back to top