Load Testing your APIs

Load Testing Your APIs For High Traffic

This month we released our flagship product for Apple devices – Teeevo. It’s an entertainment tracking application that allows you to keep track of movies and TV shows that you have already seen, planning to watch or are eagerly anticipating. It is especially frustrating to remember the last seen episodes on TV shows when your watch list is huge and you switch between different genres and shows. You can check out the complete details about the app here in case you are interested in finding out more.

After spending the last 6 months developing the v3 of this product, all of us at office was equally excited and anxious. You would of course want your application to perform well and hope you have taken care of all the nitty gritties, tested all use cases and data flows. But what if our app goes viral and starts trending on the app store? Will our servers be able to handle that kind of traffic?

There are multiple ways to handle scalability. Since our servers are hosted on Amazon, I could enable auto scaling and ensure that server capacity is automatically increased as traffic increases. But even before I can take that step I first need to calculate and analyse the kind of load my users will generate and if it makes sense. If just 100 concurrent users are generating a crazy amount of load on my servers it would mean my code is leaking memory and not optimised. So as a first step I need to test that out.

To give you some context, here are some of the initial screens and features within the app:

What I will try to do now is simulate usage of the above screens by hitting the APIs that interact with these screens. So for example, I need to do the following:

  1. Registration
  2. Login
  3. Apply Theme
  4. Select Genre(s)
  5. Get Current User’s Dashboard
  6. Get Trending TV Shows
  7. Get Trending Movies

To make this simple, I have created functions to consume each of the above APIs. I have created a lib.js file which stores all of these.


Next step is to call these functions in a logical sequence which resembles a user’s interaction with my app. Here’s my index.js file.


Now if I run my index.js in the console, it will start up a web server that listens on port 3000. Any requests then made to ‘http://localhost:3000’ would then execute the above API methods in the required sequence thereby simulating 1 user’s interaction with my app.

Let me go ahead and try that out.

And back in my console, here’s what’s happening..

This is exactly how my application server would interact with an actual user. So I have succeeded in simulating exactly one user as of now. But what if I want to simulate 100s of parallel/concurrent users? That would be the acid test for our code and server infrastructure.

Say Hi to Seige

Seige is an HTTP load testing and benchmarking tool. In a nutshell, you give it a URL and specify the number of concurrent requests that should be sent to the URL. That’s it. It will start hitting it and put your server effectively under a lot of load. This is an absolute must have tool for all sys admins and developers alike. You can read about it in detail here.

Back to my use case, let’s say I want to simulate 10 concurrent requests. All I have to do is hit the following from my command line.

If I now login to my Amazon cloud console and take a look at my server metrics, here is what I get:

You can see that immediately there is a spike on my CPU utilisation. I could go on and simulate 100s of users to test out if my server what is the no. of users needed to eventually crash my server. This helps me plan out the kind of scaling and load balancing configurations that I would need to support massive traffic that my app can generate. It would also be super helpful in estimating server costs to support user growth at a massive scale.

The above exercise helped us optimise our API codes and plan server capacity during the public release of our Teeevo iOS app. At the time of writing this article there are 17000+ users on our platform and thankfully there are no red flags as yet!

Leave a Reply