In today's fast-paced digital world, databases are at the heart of almost every application or service. Databases are responsible for storing and managing vast amounts of data, providing real-time access to information, and powering critical business operations. As the amount of data and the number of users accessing databases continues to grow, it is essential to ensure that they can handle the expected workload and perform efficiently under heavy traffic. Whether you are launching a new application or getting ready for peak traffic, load testing helps you ensure that your database can handle the load and deliver reliable performance.
While most database queries typically happen through an application endpoint, there are situations where it is beneficial to directly test the database without involving intermediaries. One such scenario is when you want to assess the performance of a specific query without executing every query in the system or to evaluate the performance of a new query under heavy load. It could also be that your database is used by multiple applications.
In this blog post we will look at load testing Azure SQL Database using Azure Load Testing. You can use a similar approach to test other databases on Azure like MongoDB, PostgreSQL etc. We will cover everything you need to know, from setting up your JMeter script, to running the load test and identifying performance bottlenecks.
Setting up Azure SQL Database
The first step in load testing an Azure SQL Database is setting it up. You can use an existing Azure SQL Database instance. For this blog post, we'll use a sample database. You can create your own sample instance using the Azure portal.
Once you have created the instance, note down the server name, database name, and login credentials. You will need these details later to connect JMeter to the database. Make sure to allow Azure services and resources to access your Azure SQL server as shown below.
Setting up the JMeter script
To load test your Azure SQL DB you will need to download the Microsoft JDBC Driver for SQL Server . You can download the driver here. Follow the steps below to. You use the artifacts from the samples repository to set up the load test.
- Open JMeter and create a new test plan. In your JMeter Test Plan browse and choose the JDBC driver.
- Add a JDBC Connection Configuration element to the test plan.
- The server name, database name , and login credentials for the Azure SQL Database instance are parameterized and can be provided using environment variables and secrets. You can store the password in an Azure Key Vault and access the same in your JMeter script using the GetSecret function. See the using secrets in Azure Load Testing docs for more detail.
- Add a Thread Group element to the test plan.
- Configure the Thread Group element to simulate the desired number of users and requests. In this script we have parameterized the concurrent threads (users) and duration as environment variables.
- Add a JDBC Request element to the Thread Group.
- Enter the SQL query that you want to execute on the Azure SQL Database instance. You can add multiple requests for multiple queries.
- If your queries require input data, you can add a CSV input file to provide data to the JMeter script.
Running the load test
You can now run this script on Azure Load Testing.
- Create an Azure Load Testing resource if you don’t already have one.
- Create a test by selecting Upload a JMeter script.
- Upload the JMeter script, the JDBC driver and the CSV file. You need to upload this because it is not already installed on the test engine.
- In the parameters tab, add the following.
- The environment variable values for the following
- threads – the number of concurrent users per engine
- duration – the duration of the test.
- Database – the database URL
- Username – the username to login to the database
- The password as a secret. Enter the secret name and the secret identifier from the Azure Key Vault (AKV). Remember to grant ‘Get’ permission on secrets to this load testing resource on the AKV using managed identity.
- The environment variable values for the following
- In the Monitoring tab, select your Azure SQL database instance. By default you can view the CPU percentage, connections failed and deadlocks for your SQL database.
- Select Review + Create to create and run the test.
Monitoring
Once the test run starts, you can monitor the client side and server side metrics on the dashboard in real time. The load begins to ramp up slowly to 150 virtual users and after the load reached the maximum virtual users, the database started returning errors. The errors are of type ‘request limit has exceeded’.
You can monitor the server side metrics as well to understand the reason for errors. You can click on Configure metrics to add additional metrics to monitor the performance of your database. As you can see, the average CPU percentage and average DTU percentage peaked after some time. Azure SQL Database recommends setting alerts for if the average CPU and DTU percentage go above 80%.
Fixing performance bottlenecks
Once you have identified performance issues, you can take steps to optimize the performance of your Azure SQL Database. Some tips to improve the performance of your Azure SQL Database include:
- Index optimization: Ensure that your database has the appropriate indexes to speed up query execution.
- Query optimization: Optimize your SQL queries to ensure that they are as efficient as possible.
- Scaling: Consider scaling up or out to increase the capacity of your Azure SQL Database.
In this case I know that my database is not able to handle the load because of the limit in DTUs. Now scale up the Azure SQL Database to 200 DTUs. Once done, re-run the test in Azure Load Testing and monitor the metrics.
Now I see that there were no errors and the average CPU and DTU percentages were within acceptable limits.
Conclusion
In conclusion, load testing is an essential aspect of database performance testing. It helps to identify performance bottlenecks, improve database performance, and ensure that it can handle the expected workload. Remember, load testing should be an ongoing process, so make sure to integrate load tests in your CICD workflows to identify any issues early in the development lifecycle and optimize your database's performance.
If you have any feedback on Azure Load Testing, let us know through our feedback forum. Refer to the previous blogs on Azure load testing here. The resources used in this blog post are available in the Azure Load Testing samples repository.
Happy Load Testing!