Almost every app runs on the client-server principle. The server and client are connected through an API, which can be tested. To test the API, you can simulate multiple users accessing the app simultaneously in different situations.
The software isn’t useful when it isn’t scalable and isn’t able to handle the required number of users. So how can you check if your app really can handle all the users you’re expecting? The answer is load testing. With load testing and knowing how to create an API load test, you’ll be all set to avoid unexpected problems with app performance.
In this article, we’re going to dive into the core of API load testing and show how to do load testing and how Yalantis helps clients achieve scalability and smooth app performance.
Load testing is a vital part of API testing. We’ve already looked at API testing, its benefits, and its performance in one of our other articles. Read it if you want to learn more about API testing.
How to execute API load testing
During load testing, QA specialists simulate many users accessing the app simultaneously. The number of users might considerably impact the API’s behavior. Consequently, load API tests work by sending specific requests to one endpoint in order to check how the system behaves under normal or peak load conditions.
From one workstation, a QA specialist is able to send hundreds of requests in parallel thanks to multithreading. And a QA specialist can run more than one workstation if needed to simulate real user activity and gather essential data.
Load testing normally takes place after the first testing cycle, whether automated or manual. At this stage, the system should have good performance overall.
If your project has budget and time limitations, we suggest starting load testing closer to the end of development as by that time we already know where possible bottlenecks can be found and how to tune performance of your app.
What do you achieve with load testing?
Smooth and fast performance – Slow server response times lead to lost users, as people prefer fast sites and so does Google. Research conducted by Google indicates that 53 percent of mobile users will leave a web application page if it takes longer than three seconds to load. Proper use of load tests saves money, time, and your app’s reputation by making sure it meets your business needs from the very beginning.
Stability – If your application stops responding to user requests or if errors occur, users will leave your app. As application performance depends on the API, it’s common practice to use load testing.
Comprehensive statistics for measuring KPIs – During load testing, QA specialists gather categorized statistics on response times to find out if they meet the API provider’s requirements. For example, some providers require for their API server response times of less than two seconds for performance reasons. These statistics show if the app meets predefined KPIs: minimum, average, and maximum response times, number of errors, requests processed by the server per second, and so on. With this information, you can find out if your app is able to handle the expected load on its backend servers and if it’s actually viable.
[Statistics for measuring KPIs]
Load testing at Yalantis
Load testing involves several approaches and tools. Which approach and set of testing tools to choose depends on your project requirements. We’ll describe the most commonly used approach.
So, what does a load tester do? A QA specialist at Yalantis take the following steps to perform load testing:
1. Plan scenarios for load tests
Load testing requires planning. During the first phase of project planning, the business analyst collects nonfunctional requirements against which performance metrics will be checked. Based on these requirements, we prepare a test script and one or more test scenarios.
As a result of planning, our specialists decide on the relevant approach and its components, as load testing can be performed using two approaches.
The first approach is longevity testing, which checks if a system can withstand a constant moderate workload for a long time. The second approach is volume testing, which subjects a system to a big workload for a limited time. These approaches both identify bottlenecks, bugs, and component limitations.
For instance, backend servers might have a fast processor but limited memory. Load testing gives developers a general idea of the number of apps or processes that can be run at the same time while sustaining the rated level of performance. Expected use cases and possible changes in API request traffic are also taken into account.
As a rule, we perform longevity testing for large enterprise apps, as they require stable API performance. On the other hand, we use volume testing when heavy data is processed on a daily basis. Volume testing is recommended for shopping, payment, and ticket booking apps.
We typically use Gatling or Apache JMeter for load testing.
This tool helps us quickly create different checkout load test scenarios. As the script runs, Gatling creates an informative HTML report showing the response time of each request.
[Report with statistics for planning scenarios in Gatling]
This tool has a GUI (graphical user interface) mode that enables our specialists to make test plans manually, select from templates, or record the app from a browser session. Additionally, GUI mode provides debugging and the ability to look through test results. If we have a ready plan, we use the non-GUI mode to execute a load test from the command line. You can save test results to an HTML, CSV, or XML file.
[Creating test plans in Apache JMeter]
2. Load testing after the planning stage
Our QA specialists set the number of requests to send, the test script, and the time to perform the test. Afterwards, each request targets the API for a fixed period as the testing tool notes the performance.
While performing load testing, we check the performance metrics against nonfunctional requirements collected by our business analyst during the planning stage.
We also apply correlation – a method used to identify which response from the server is dynamic (able to return different data for each request, which periodically influences successive requests) and which is static (doesn’t change). Correlation is essential to handle dynamic content and can be omitted only when testing pages with static content, such as some home pages.
When modeling Black Friday for an online marketplace, for example, we expect a much larger number of people than usual to visit and we expect them to stay longer to find discounts.
In this case, our team would analyze KPIs like response time, throughput, latency, and connection time as well as the correlations between these KPIs to see how to improve the system’s capabilities. Once improvements were made, we would run the test again.
After load testing is performed and data collected, we define next steps for further improvements. For instance, we apply a scaling strategy in case an app isn’t able to handle the expected growth in users, data volume, etc.
If the system, processes, and databases can’t meet the increased demand, we use additional servers, increase their power, or use load balancers to correct the situation. We also can resort to additional services that provide the needed capacity.
3. API load testing tools used at Yalantis
Specialized testing tools enable a team of developers to determine if the system performs as expected and what issues may take place at high load. A worthwhile load testing tool should be capable of:
setting up performance testing within the software supply chain;
providing high-level performance testing, shortening the build/test cycle;
allowing collaboration between developers and QA specialists.
We use Gatling and Apache JMeter for load testing, as we know that they provide this functionality. Let’s look at them in detail.
Gatling is an open-source load and performance testing tool. It uses the Scala programming language, Akka toolkit, and Netty software as its tech stack. The following are some additional reasons why we use Gatling:
It runs on any system – You can use multiple local servers/machines as well as cloud servers to prepare and run tests.
It lets you embed load tests similarly to source code – This enables you to store your tests in version control systems that facilitate collaboration, keep a record of all changes, save all optimization work, etc.
It provides informative dashboards – There’s no need for any extra plugins, as you can see interactive HTML reports right after tests are performed.
It has an advanced architecture – Thanks to its architecture, Gatling provides high-quality test execution.
JMeter is an advanced open-source load testing tool with lots of worthwhile features. It can imitate a huge load on a server by making lots of requests. JMeter can be used instead of Gatling and has its own advantages:
Usability – JMeter is a pure Java desktop app and is ready for use with its default load testing settings. You don’t need to have any special skills or domain knowledge to get started.
Ability to run on any operating system – Java is the most widely used language in the world, and the Java-built JMeter is able to run on nearly any operating system. It makes no difference if it’s Windows, Linux, or macOS.
Effective reporting – You can view test results in graphs, charts, and tree view. JMeter supports various formats for your reports such as XML, HTML, JSON, and any text format.
Logic controllers for setting up tests – Logic controllers are a unique feature of JMeter. They provide excellent flexibility to set up tests in the GUI. Logic controllers customize the logic that JMeter uses to choose the right time for sending requests. Logic controllers can change the order of requests, modify and repeat them, etc.
How load testing helped Yalantis deliver a project serving a good purpose
One of our recent projects – World Cleanup Day – offers a good example of successful load testing. World Cleanup Day is a worldwide event that took place on September 15, 2018. Millions of individuals all over the world gathered in their local communities to clean up waste.
Yalantis helped the organizer of this event to build an improved version of their mobile application. You can read about the project details in our case study.
One of the main features of the app is a map with trashpoints. Users can create trashpoints to signal other volunteers to clean up certain areas. Since our clients expected 17 million volunteers to use the app on World Cleanup Day, we needed to make sure that the map would work properly.
We emulated different numbers of users viewing the map simultaneously to see:
trashpoints and events at different scales;
social flow with commands and the ability to change the status of trashpoints.
[World Cleanup Day app developed by Yalantis]
We used two testing methods:
gradually increasing the number of users until the system failed;
simulating peak loads of 100, 300, 500, and more simultaneous users.
These tests enabled our team to check how the system responded to simultaneous requests.
After performing load testing, we defined bottlenecks and found out how to get rid of them. As a result, we increased the capacity for simultaneous users by 50 times. You can find out what helped us to deliver these results in our case study.
API load testing is often justified. Of course, there are exceptions to every rule. If your project hasn’t attracted an audience yet or if you already know your server’s abilities and don’t expect a rush of new users, there’s no need for load testing. In all other cases, we highly recommend it.
In order to ensure effective load testing, we need to understand anticipated user growth. To save resources, it’s also important not to over-optimize the system – for example, by making it available for millions of users if the expected number of users is no more than 50.
We usually advise our clients to use the cloud infrastructure provided by Amazon Web Services. Its horizontally scalable structure ensures effective load testing. If you’re considering API load testing for your project, contact us. We’ll take an in-depth look and provide you with a detailed consultation.