Discover your application’s breakpoint using Azure Load Testing

You’ve been assessing the performance of your application. You’re confident that it’s functioning well. So, what next?

You can take it one step further and determine when exactly your application will break by pushing its limits. This is called breakpoint testing. It helps you identify the maximum requests per second that your application can handle before the performance degrades. Even if you don’t expect as many users as requests per second, it’s important to discover your application’s breakpoint and verify that your application can recover without a lot of effort. It also helps in understanding which component of your application fails first and why.

As the product manager for Azure Load Testing, I've been working with many customers to validate our preview release. Some of them have discovered their application’s breakpoint by testing different load configurations before noticing a performance degradation.

Let’s walk through the process. We’ll run a load test on a sample application hosted on an Azure App Service and Azure Cosmos DB to identify its breakpoint.

(The following steps assume that you have already created a load testing resource in Azure Load Testing. If not, you can get started by creating an Azure Load Testing resource.)

Step 1: Create and run the test:

1. Configure your Apache JMeter script to generate linear load. Edit your JMX file to set the following values for your thread group, so that your load ramps up at a constant rate throughout the test:
   1. Number of threads: The desired number of users per virtual users. We recommend setting the number of threads to a maximum of 250.
   2. Ramp-up period: Duration of the test
   3. Loop count: Infinite

Screenshot that shows linear load configured in a JMeter script.

2. Navigate to your Azure Load Testing resource in the Azure portal. Create a test by uploading your JMeter script with the following configuration:
   1. On the Load tab, select the number of engine instances you want to run the test with. For the first test run, you can go ahead with the default of one engine instance.
   2. On the Monitor tab, make sure to select your app component resources to monitor the server-side metrics.
3. Azure Load Testing will automatically create a test run. Observe the response time and error rate during the test run.

   If you see a significant increase in response time or errors, then your application might have reached its breakpoint. You can skip ahead to Step 3 for more insight.

   However, if the response time was constant throughout and there were no errors throughout the test (as you can see below), you need to increase the load to identify the breakpoint. We’ll go through this process next.

Screenshot that shows a test run with constant response time and no errors.

Step 2: Keep increasing the load:

1. Modify the test to increase the load.
   1. On the test run dashboard, click on View all test runs.
   2. Click on Configure and select Test.
   3. On the Load tab, increase the number of engine instances. In this case, I have increased it to 3 engine instances.
2. Run the test and monitor your application’s response time and error responses for any degradation. If not, keep increasing the number of engine instances for the subsequent runs until you are able to identify the breakpoint.

Notice below that the test run I ran for this application shows a sudden increase in the response times and errors. At the same time, the number of requests per second reduced significantly.

Screenshot that shows a sudden increase in the response times and error responses.

Step 3: Discover the breakpoint

During the test, as the number of virtual users increases, after a point we see significant increase in the response time and the number of errors. Depending on your requirements, when you see a significant increase in response times and errors as your users increase, you can consider any point during this period as the application’s breakpoint.
For example, if your application requires an error rate of zero percent, you can consider it a breakpoint when errors first start appearing during your test. Or if the application’s response time is critical, then the breakpoint occurs when the response time exceeds a threshold you set.
In this case, I’m defining the breakpoint when the application starts to return 500 errors. The breakpoint for aggregate requests is 215 requests per sec. If your application does not meet the minimum acceptance criteria of requests per second, then it requires tuning.

Screenshot that shows the application's breakpoint in the requests per second chart.

Step 4: Determine the failing components

By monitoring the server-side metrics, you can identify which component failed first. As you can see from the metrics for this sample application, the Azure App Service plan, the CPU percentage, and the Memory percentage metrics are within an acceptable range. Notice that the Normalized RU Consumption metric shows that the database reached 100 percent resource utilization at the breakpoint. Increasing the provisioned throughput of the database might improve performance.

Screenshot that shows resource utilization of server side components.

In summary, we looked at how to determine an application’s breakpoint using Azure Load Testing. We also went through how to use criteria to determine which application components act as the first bottleneck at the breakpoint.
Use the comments section to let the community know if you were able to discover a breakpoint during your test run. If you have any feedback on Azure Load Testing, let us know using our feedback forum.

Happy breakpointing!