API Performance Testing: Getting Started

By Load Impact . On 2017-09-12

API load testing doesn’t have to be confusing and complex. As with so many things, a major part of what you need to do is not that complex. You can cover the majority of what you need to test with your API with a simple, straightforward plan and setup. Once you’ve done that, feel free to make it more difficult and complex. Until then, here’s how to load test your API the easy way.


First, let’s make sure we’re using the same words to mean the same things and define our terms. In a site or app, we start with discussing “VUs,” or virtual users that simulate actual users and their behavior. Since there’s no human user for an API, we measure other things, like response time based on requests per second (RPS). Watching response time as you increase API RPS is a great place to start.

Similarly, the easiest way to test anything, whether site, app or API, is to start with a baseline test. So when you test an API, start with the baseline test first. Since we established that we want to start by measuring API response time at different RPS levels, let’s figure out how to configure our load test appropriately.

Our general rule of thumb is to estimate 25 RPS per VU. Let’s unpack that: in other words, most load testing tools like Load Impact and k6 set testing parameters in VUs, and we want RPS for our API testing. To easily translate between the two, use that 25 multiplier. For example, if you have a private API and don’t expect more than 10,000 partners to be using the API at the same time, you’d set your load testing at 10,000/25 = 400 VUs to start.

Thus, you can set your baseline tests to consist of HTTP-based API requests at that baseline VU number you estimated. How does your API respond when you run the test? Does performance remain consistent? Does it perform consistently across different parameters?

Now that you’ve run this baseline test, you can run the same test on a regular schedule to gauge how different code changes might have affected performance. Plus, with an API call, you may also find that infrastructure or database changes can affect data or processing requests. Track performance trends and issues. Remember, we recommend you continually load test during the development process. (See why here.)

The baseline test is the most important test to run (and repeat). But don’t overlook capacity testing: you will still want to know exactly what it takes to “break” your API - or stress it to the point that performance becomes unacceptable. Try increasing the VU number - remembering that each VU represents an estimated 25 RPS - until you see performance affected. Adjust and repeat.

Since an API is all “back end,” there’s no UI to test, but be sure to watch for integration points or dependencies. If your API aggregates other internal services, watch to see which could be a weak point, for example.

To dig in deeper, check out our in-depth article, complete with a customizable testing script, in this support article.

Happy testing!