If you have an API, you should be load testing it. You should test it frequently and consistently.
With that out of the way, here’s why: API consumers are like your end users of a website or app. Yet unlike sites or apps, APIs don’t have front ends or usage paths to follow. Instead, assuming you’ve built the right capabilities into your API, everything comes down to performance.
So basic testing of your API is fine when you want to achieve “works on my machine”-level performance. But that isn’t enough for professional use.
Instead, you should be testing your API’s performance under load - seeing how it will perform under the stress of multiple consumers. In other words, your REST API shouldn’t spend any time resting at all.
As we have suggested before, let’s make sure we agree on how we’re using some terms. If you’re familiar with load testing, you’re also familiar with the term “virtual users,” often abbreviated as “VUs.” Most load test services - like LoadImpact - estimate the size of the load tests you run using VUs.
Yet VUs don’t really apply when you’re testing an API. Instead, we generally gauge the size and performance of an API load test not in VUs but in requests per second, or “RPS.” Still, most tools, like ours, will require you to set up the size and scope of your load test in VUs, not RPS. As a general rule of thumb, we suggest you estimate about 25 RPS per VU. So if you anticipate your highest potential traffic load at 10,000 RPS, you’d set up your test for 400 VUs.
You will be able to set your appropriate baseline test - how your API performs under “normal” load - based on what you see in your logs as past usage patterns. You should run that same baseline test regularly, even with every major release or build, to make sure your code changes didn’t inadvertently introduce any performance issues. (Remember, it’s not just your code that can cause slowdowns: database access and network speed can affect it as well.)
(As a reminder, we believe you should load test consistently and continually during any software development process. Read more here.)
You’ll also want to consistently run stress tests, increasing the number of RPS (VUs) until you start to see performance issues. This helps you solve problems before you are faced with them during a crunch period, often the worst time to discover where your systems may be weak.