Troubleshoot failing load tests in Azure Load Testing

Learn how to diagnose and troubleshoot errors while running a load test with Azure Load Testing. Download the Apache JMeter worker logs or load test results for detailed logging information. Alternately, you can configure server-side metrics to identify issues in specific Azure application components.

Azure Load Testing runs your Apache JMeter script on the test engine instances. During a load test run, errors might occur at different stages. For example, the JMeter test script could have an error that prevents the test from starting. Or there might be a problem to connect to the application endpoint, which results in the load test to have a large number of failed requests.

Azure Load Testing provides different sources of information to diagnose these errors:

Prerequisites

  • An Azure account with an active subscription. If you don't have an Azure subscription, create a free account before you begin.
  • An Azure load testing resource that has a completed test run. If you need to create an Azure load testing resource, see Create and run a load test.

Identify load test errors

You can identify errors in your load test in the following ways:

  • The test run status is failed.

    You can view the test run status in list of test runs for your load test, or in Test details in the load test dashboard for your test run.

    Screenshot that shows the load test dashboard, highlighting status information for a failed test.

  • The test run has a non-zero error percentage value.

    If the test error percentage is below the default threshold, your test run shows as succeeded, even though there are errors. You can add test fail criteria based on the error percentage.

    You can view the error percentage in the Statistics in the load test dashboard for your test run.

  • The errors chart in the client-side metrics in the load test dashboard shows errors.

    Screenshot that shows the load test dashboard, highlighting the error information.

Download Apache JMeter worker logs

When you run a load test, the Azure Load Testing test engines execute your Apache JMeter test script. During the load test, Apache JMeter stores detailed logging in the worker node logs. You can download these JMeter worker logs for each test run in the Azure portal. Azure Load Testing generates a worker log for each test engine instance.

For example, if there's a problem with your JMeter script, the load test status is Failed. In the worker logs you might find additional information about the cause of the problem.

To download the worker logs for an Azure Load Testing test run, follow these steps:

  1. In the Azure portal, go to your Azure Load Testing resource.

  2. Select Tests to view the list of tests, and then select your load test from the list.

    Screenshot that shows the list of load tests for an Azure Load Test resource.

  3. Select a test run from the list to view the test run dashboard.

  4. On the dashboard, select Download, and then select Logs.

    The browser should now start downloading a zipped folder that contains the JMeter worker node log file for each test engine instance.

    Screenshot that shows how to download the test log files from the test run details page.

  5. You can use any zip tool to extract the folder and access the log files.

    The worker.log file can help you diagnose the root cause of a failing load test. In the screenshot, you can see that the test failed because of a missing file.

    Screenshot that shows the JMeter log file content.

Diagnose failing tests using test results

To diagnose load tests that have failed requests, for example because the application endpoint is not available, the worker logs don't provide request details. You can use the test results to get detailed information about the individual application requests.

  1. Follow these steps to download the test results for a load test run.

  2. Open the test results .csv file in an editor of your choice.

  3. Use the information in the responseCode and responseMessage fields to determine the root cause of failing application requests.

    In the following example, the test run failed because the application endpoint was not available (java.net.UnknownHostException):

    timeStamp,elapsed,label,responseCode,responseMessage,threadName,dataType,success,failureMessage,bytes,sentBytes,grpThreads,allThreads,URL,Latency,IdleTime,Connect
    1676471293632,13,Home page,Non HTTP response code: java.net.UnknownHostException,Non HTTP response message: backend.contoso.com: Name does not resolve,172.18.44.4-Thread Group 1-1,text,false,,2470,0,1,1,https://backend.contoso.com/blabla,0,0,13
    1676471294339,0,Home page,Non HTTP response code: java.net.UnknownHostException,Non HTTP response message: backend.contoso.com,172.18.44.4-Thread Group 1-1,text,false,,2201,0,1,1,https://backend.contoso.com/blabla,0,0,0
    1676471294346,0,Home page,Non HTTP response code: java.net.UnknownHostException,Non HTTP response message: backend.contoso.com,172.18.44.4-Thread Group 1-1,text,false,,2201,0,1,1,https://backend.contoso.com/blabla,0,0,0
    1676471294350,0,Home page,Non HTTP response code: java.net.UnknownHostException,Non HTTP response message: backend.contoso.com,172.18.44.4-Thread Group 1-1,text,false,,2201,0,1,1,https://backend.contoso.com/blabla,0,0,0
    1676471294354,0,Home page,Non HTTP response code: java.net.UnknownHostException,Non HTTP response message: backend.contoso.com,172.18.44.4-Thread Group 1-1,text,false,,2201,0,1,1,https://backend.contoso.com/blabla,0,0,0
    

Diagnose failing tests using server-side metrics

For Azure-hosted applications, you can configure your load test to monitor resource metrics for your Azure application components. For example, a load test run might produce failed requests because an application component, such as a database, is throttling requests.

Learn how you can monitor server-side application metrics in Azure Load Testing.

For application endpoints that you host on Azure App Service, you can use App Service Insights to get additional insights about the application behavior.

Next steps