Have you ever had the thought of simulating real-life users on your API or service, or have you ever wanted to put your API to the test, to see how much it can and can not handle, to make informed decisions, like optimize your code better or consider scaling your server, horizontally or vertically? Well, I have, on multiple occasions, but apart from writing unit and e2e tests, I have never really gone ahead to run actual performance tests, the reasons being we usually had a QA engineer on the team, and for personal projects, I felt nonchalant and convinced myself it wasn’t necessary.
But here's the issue: It's not about whether I need it in my personal project that will never get up to 5 active users; it's about giving myself a chance to learn something new. I believe having this knowledge/skill will really make you stand out as a software engineer or backend engineer
Knowing how to test your API performance will help solidify your knowledge of whatever technology or framework you're using to build. When you run a test, you notice an issue, and then you go back to your IDE to figure out if it's a query, a join statement, or data manipulation logic that's the issue, you start to ask yourself questions and dig deeper, you select better data structures, you improve your SQL statements, you consider implementing caching, you realize you're making multiple calls to the DB for the same items, and you realize your code structure is looking like a plate of spaghetti from the Bear movie. At the end of all these, you come out a bad-ass engineer. What you learn from performance testing is endless.
I am a backend-heavy software engineer. If you ask me who a backend engineer is in 2025, my answer would be someone who does backend work, understands systems design, is knowledgeable about best dev-ops practices and performance testing, and has a good background in data structures and algorithms. So you need this stuff if you really want to skill up, scale up, and take up senior roles.
What are the types of performance testing?
Before I go on to the types of performance testing, I want to mention that the first step to actually testing your API's performance is by writing proper unit, integration, and e2e tests, and making sure to cover as many edge cases as possible. I know it's for functionality, but come on, you don't have those ones present and you're bothered about performance?
Now, to address the elephant in the room, there are various types of performance testing as shown below. For easy understanding and brevity, I used the explain-example-result format.
So, let's start with load testing, which is primarily carried out to evaluate how a system performs under expected user loads or usage.
Scenario:
You are launching an e-commerce website, and you expect 500 users to browse and shop simultaneously during peak hours.
- A load test simulates 500 concurrent users browsing the site, adding items to carts, and checking out.
- Metrics: Response time, database query times, and server resource utilization under this expected load.
- Goal: By identifying slow database queries or underperforming endpoints during load testing, you can optimize these areas to provide a seamless user experience, preventing potential revenue loss during high-traffic periods.
We have tested the system's capability in handling a normal scenario, or expected usage level. Now we want to find out the system's breaking point, by applying a load beyond its capability. That's where Stress Testing comes in.
Scenario:
You want to understand how your social media platform handles traffic spikes, such as during a viral event.
- A stress test simulates 50,000 users simultaneously posting, liking, and commenting—far exceeding normal user activity.
- Metrics: System stability, error rates, and recovery time after failure.
- Goal: By conducting stress tests, you gain insights into failure thresholds and recovery strategies, which are crucial for maintaining user trust and business continuity during high-demand scenarios.
There are cases where we might be expecting the system usage or traffic to increase, maybe double or triple, and you want to make sure you have everything in place, that's what Scalability Testing is for, to test the system's ability to scale up or down with increased load or resource availability.
Scenario:
Your video streaming app plans to add 1 million users next year, doubling the current base.
- A scalability test increases the number of concurrent users incrementally (e.g., 10,000 to 50,000) and observes system performance.
- Metrics: Server response times, database performance, and horizontal or vertical scaling efficiency.
- Goal: Scalability testing helps validate whether your infrastructure investments, such as autoscaling or database sharding, are effective and ensure the app remains competitive as user demands grow.
And now, Volume Testing ---If you're expecting a large number of users, or your application is data intensive, you probably want to make sure your system can handle a high volume of data and still maintain optimal performance.
Scenario:
Your financial application must process and store 10 million daily transactions.
- A volume test loads the database with a large dataset (10 million transaction records) and tests retrieval, updates, and queries.
- Metrics: Query execution time, disk I/O, and database index performance.
- Goal: By validating database performance under high data loads, volume testing ensures seamless operations for end-users and reduces the risk of downtime during critical transactions.
Lastly, we have Endurance Testing (Soak Testing) which is usually carried out to check the system's stability and performance over an extended period.
Scenario:
Your online gaming platform needs to handle 20,000 concurrent players for 48 hours without downtime or memory leaks.
An endurance test simulates continuous gameplay by 20,000 users, including saving progress and multiplayer interactions, over two days.
- Metrics: Memory usage, CPU utilization, and error rates over time.
- Goal: By uncovering resource leaks or degradation, endurance testing helps maintain user satisfaction and avoids costly downtime, especially in critical applications requiring high availability."
Now that you have discovered some issues in your project, resolving them should be the next thing on your agenda. There are various ways to resolve these issues, some of which are:
Query Optimization:
Here, you want to go back to IDE to improve the efficiency of your DB queries, and access patterns which may have resulted in an ~N+1 selects problem~.Bottleneck Analysis:
Bottleneck Analysis is usually the go-to first step because it identifies specific parts of a system (hardware or software) that limit performance, and suggests targeted optimizations like indexing, query restructuring, or load balancing. During bottleneck analysis, you're able to pin-point low database queries, overloaded threads, or network latencyCall Tree:
A call tree analysis will help you resolve issues that arise from a hierarchical representation of function calls, such as situations where functions call others and for some reason that process takes a long time to resolve.Resource Contention Analysis:
Resource Contention Analysis involves examining how shared resources (e.g., CPU, memory, database connections) are utilized and if contention arises. It helps to identify race conditions or deadlocks under high loads and to optimize thread pools.Diagnostics:
Perhaps you have some diagnostic services like Sentry, New Relic, Datadog, or Prometheus set up in your server, diagnostics involve collecting and analyzing logs, traces, and metrics from these services to identify the root cause of issues during performance testing
Platforms and Tools for performance testing
There are a lot of these tools available, but in other to keep this article short, I will have to mention a few.
In order to run performance testing, you have to leverage tools like PyCharm Profiler / Django Debug Toolbar to pinpoint performance issues in code, k6(Great for APIs and microservices), Load Runner, Locust(for Python), BlazeMeter(Can be integrated in CI/CD pipelines), HammerDB and Database Benchmark for volume testing.
To select which is best for you, consider your technology stack, the scale of the project, ease of use, and your budget(K6, JMeter, and Locust are the go-tos because they are cost-effective and open-source).
Each type of testing ensures your service is prepared for different real-world scenarios, from handling normal traffic to extreme and prolonged conditions.
If you found this article useful, please consider leaving a like or a comment to share your thoughts, opinions, or experience in performance testing.
Top comments (0)