The functional requirements of a web-based application or web portal are usually clear and easily verifiable, except for the most complex processes. However, non-functional properties are always more difficult to test and validate.
How many concurrent users can use it without affecting performance? What happens when users get too large? What happens when a redundant piece of the solution goes down?
To answer these questions, very specific tools are needed, sometimes expensive, with a configuration that is usually complex. To try to facilitate this process in terms of effort and cost, Microsoft has launched Azure Load Testing on the market.
Azure Load Testing is a fully managed load testing service that enables you to generate a concurrent user load to a large-scale application.
The service simulates application traffic, regardless of where applications are hosted and can be used to optimize application performance, scalability, or capacity.
With just the application URL, Azure Load Testing abstracts away the complexity and infrastructure to run a large-scale load test. In addition, this service allows us to automate regression tests by running load tests as part of the continuous integration/continuous deployment (CI/CD) workflow and pulling back versions that fail these tests and regression tests. their regression.
In Azure-based applications, Azure Load Testing is easily implemented and collects more detailed resource metrics to identify performance bottlenecks in Azure application components.
In other Cloud environments, private connection points, or On-Premise Applications, Azure Load Testing will also allow us to carry out load tests, with additional configuration before giving access to the service.
In addition, Azure Load Testing allows us to create a load test by reusing an existing test script from Apache JMeter (another of the open-source load and performance tools), for more complex cases where user actions in virtual worlds must be more dynamic and varied. For example, the test plan may consist of requests to multiple applications or use different parameters and login data.
Once a load test has been executed, the results of the test can be consulted in a Dashboard with the information of the test, with data of the results and graphs, as well as additional data in components in Azure. In this way, bottlenecks and performance problems in the studied applications can be identified. The service also maintains a history of results, allows you to compare results visually, and also allows you to download results and use third-party tools to analyze them.
The Azure Load Test service is initially priced and then priced based on virtual users/hours used during testing.
Azure Load Testing Test Engines abstract the infrastructure needed to run a large-scale load test. The test engines run a provided Apache JMeter script to simulate many virtual users concurrently accessing the application endpoints.
In the case of creating a load test based simply on a URL, Azure Load Testing automatically generates the Apache JMeter test script. Also, to scale the load test horizontally, the service allows you to configure the number of test engines.
Azure Load Testing uses Apache JMeter version 5.5 to run load tests. And the app can be hosted anywhere:
On the other hand, to perform load tests in cases where there is no public endpoint, Azure Load Testing must be implemented in a virtual network.
During the load test, the service collects the following resource metrics and displays them on the Dashboard:
Azure Load Testing automatically incorporates best practices for Azure networking so tests run safely and reliably. Load tests stop automatically if application endpoints or Azure components initiate throttling requests.
Additionally, data stored in any Azure Load Testing resource is automatically encrypted with Microsoft-managed keys, which are service-managed. This data includes, for example, the Apache JMeter script used in the test, either entered by the user or auto-generated based on the URL.
Let’s now look at an example of how to perform a load test on our web-based application or a web portal.
Important, to perform a load test, the following prerequisites are required:
Once both conditions are met, the first step is to create an Azure Load Testing resource, which provides a centralized place to view and manage test plans, test results, and related artifacts:
Select Review + create.
We must review all the configuration options and select “Create” to start the implementation.
After the process is complete, a deployment success message will appear.
With the Azure Load Testing resource created, we can quickly create a load test from the Azure portal. To do this, it is only necessary to specify the URL of the web application and the basic parameters of the test.
Azure Load Testing creates the load test script and transparently provisions the necessary infrastructure.
To start the load test we must:
If the number of virtual users exceeds the maximum of 250 per test engine instance, Azure Load Testing provisions multiple test engines and distributes the load evenly.
For example, 300 virtual users will result in 2 test engines with 150 virtual users each. The maximum number of users allowed is 11250. The number of users used per hour influences the price of the service.
The automatically generated Apache JMeter script for the load test can be downloaded from the Execution Dashboard.
If we wanted to run the script locally, we would need to provide environment variables to set the URL and test parameters.
Once the load test starts, the page is redirected to the Execution Dashboard. While the load test is running, Azure Load Testing captures client-side metrics and server-side metrics, but the Execution Dashboard is used to monitor client-side metrics. By default, the data is updated every 5 seconds.
This execution Dashboard allows us to change the filters to see a specific time interval, resulting in percentile or type of error.
Another feature that the service has is that, at any time, we can modify the load test settings, define test failure criteria, or navigate the portal to monitor server-side metrics for components in Azure.
Once the test is complete, we can use the Azure Load Testing resource for our next tests. However, to avoid incurring unnecessary costs, we recommend reviewing the resources provisioned by the test, which will have been created in the same Resource Group, and deleting those that are not needed until the next test you want to run.