Load test a website by using an existing JMeter script in Azure Load Testing

Learn how to use an Apache JMeter script to load test a web application with Azure Load Testing from the Azure portal.

Azure Load Testing enables you to take an existing Apache JMeter script, and use it to run a load test at cloud scale. Alternatively, you can also create a URL-based load test in the Azure portal.

Use cases for creating a load test with an existing JMeter script include:

  • You want to reuse existing JMeter scripts to test your application.
  • You want to test multiple endpoints in a single load test.
  • You have a data-driven load test. For example, you want to read CSV data in a load test.
  • You want to test endpoints that are not HTTP-based, such as databases or message queues. Azure Load Testing supports all communication protocols that JMeter supports.


Create an Apache JMeter script

If you already have a script, you can skip to Create a load test. In this section, you'll create a sample JMeter test script to load test a single web endpoint.

You can also use the Apache JMeter test script recorder to record the requests while navigating the application in a browser. Alternatively, import cURL commands to generate the requests in the JMeter test script.

To create a sample JMeter test script:

  1. Create a SampleTest.jmx file on your local machine:

    touch SampleTest.jmx
  2. Open SampleTest.jmx in a text editor and paste the following code snippet in the file:

    This script simulates a load test of five virtual users that simultaneously access a web endpoint, and takes 2 minutes to complete.

    <?xml version="1.0" encoding="UTF-8"?>
    <jmeterTestPlan version="1.2" properties="5.0" jmeter="5.4.1">
        <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Azure Load Testing Quickstart" enabled="true">
          <stringProp name="TestPlan.comments"></stringProp>
          <boolProp name="TestPlan.functional_mode">false</boolProp>
          <boolProp name="TestPlan.tearDown_on_shutdown">true</boolProp>
          <boolProp name="TestPlan.serialize_threadgroups">false</boolProp>
          <elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
            <collectionProp name="Arguments.arguments"/>
          <stringProp name="TestPlan.user_define_classpath"></stringProp>
          <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Web endpoint test" enabled="true">
            <stringProp name="ThreadGroup.on_sample_error">continue</stringProp>
            <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true">
              <boolProp name="LoopController.continue_forever">false</boolProp>
              <intProp name="LoopController.loops">-1</intProp>
            <stringProp name="ThreadGroup.num_threads">5</stringProp>
            <stringProp name="ThreadGroup.ramp_time">10</stringProp>
            <boolProp name="ThreadGroup.scheduler">true</boolProp>
            <stringProp name="ThreadGroup.duration">120</stringProp>
            <stringProp name="ThreadGroup.delay">5</stringProp>
            <boolProp name="ThreadGroup.same_user_on_next_iteration">true</boolProp>
            <HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="HTTP request" enabled="true">
              <elementProp name="HTTPsampler.Arguments" elementType="Arguments" guiclass="HTTPArgumentsPanel" testclass="Arguments" testname="Sample web test" enabled="true">
                <collectionProp name="Arguments.arguments"/>
              <stringProp name="HTTPSampler.domain"></stringProp>
              <stringProp name="HTTPSampler.port"></stringProp>
              <stringProp name="HTTPSampler.protocol"></stringProp>
              <stringProp name="HTTPSampler.contentEncoding"></stringProp>
              <stringProp name="HTTPSampler.path"></stringProp>
              <stringProp name="HTTPSampler.method">GET</stringProp>
              <boolProp name="HTTPSampler.follow_redirects">true</boolProp>
              <boolProp name="HTTPSampler.auto_redirects">false</boolProp>
              <boolProp name="HTTPSampler.use_keepalive">true</boolProp>
              <boolProp name="HTTPSampler.DO_MULTIPART_POST">false</boolProp>
              <stringProp name="HTTPSampler.embedded_url_re"></stringProp>
              <stringProp name="HTTPSampler.connect_timeout"></stringProp>
              <stringProp name="HTTPSampler.response_timeout"></stringProp>
  3. In the file, set the value of the HTTPSampler.domain node to the host name of your endpoint. For example, if you want to test the endpoint https://www.contoso.com/app/products, the host name is www.contoso.com.


    Don't include https or http in the endpoint URL.

  4. In the file, set the value of the HTTPSampler.path node to the path of your endpoint. For example, the path for the URL https://www.contoso.com/app/products is /app/products.

  5. Save and close the file.


    Don't include any Personally Identifiable Information (PII) in the sampler name in the JMeter script. The sampler names appear in the Azure Load Testing test run results dashboard.

Create a load test

When you create a load test in Azure Load Testing, you specify a JMeter script to define the load test plan. An Azure Load Testing resource can contain multiple load tests.

When you create a quick test by using a URL, Azure Load Testing automatically generates the corresponding JMeter script.

To create a load test using an existing JMeter script in the Azure portal:

  1. Sign in to the Azure portal by using the credentials for your Azure subscription.

  2. Go to your Azure Load Testing resource, select Tests from the left pane, select + Create, and then select Upload a JMeter script.

    Screenshot that shows the Azure Load Testing page and the button for creating a new test.

  3. On the Basics tab, enter the Test name and Test description information. Optionally, you can select the Run test after creation checkbox.

    Screenshot that shows the Basics tab for creating a test.

  4. On the Test plan tab, select your Apache JMeter script, and then select Upload to upload the file to Azure.

    Screenshot that shows the Test plan tab.


    You can upload additional JMeter configuration files or other files that you reference in the JMX file. For example, if your test script uses CSV data sets, you can upload the corresponding .csv file(s). See also how to read data from a CSV file.

  5. Select Review + create. Review all settings, and then select Create to create the load test.

You can update the test configuration at any time, for example to upload a different JMX file. Choose your test in the list of tests, and then select Edit.

Run the load test

When Azure Load Testing starts your load test, it will first deploy the JMeter script, and any other files onto test engine instances, and then start the load test.

If you selected Run test after creation, your load test will start automatically. To manually start the load test you created earlier, perform the following steps:

  1. Go to your Load Testing resource, select Tests from the left pane, and then select the test that you created earlier.

    Screenshot that shows the list of load tests.

  2. On the test details page, select Run or Run test. Then, select Run on the confirmation pane to start the load test. Optionally, provide a test run description.

    Screenshot that shows the run confirmation page.


    You can stop a load test at any time from the Azure portal.

  3. Notice the test run details, statistics, and client metrics in the Azure portal.

    Screenshot that shows the test run dashboard.

    Use the run statistics and error information to identify performance and stability issues for your application under load.

Next steps

You've created a cloud-based load test based on an existing JMeter test script. For Azure-hosted applications, you can also monitor server-side metrics for further application insights.