Guides »

Capacity Testing: Finding Your True Maximum Load

By Andy Hawkes
Reading Time 6 Minutes

Introduction

Most performance questions boil down to a practical one: how much traffic can your system actually handle while still delivering an acceptable user experience?

That limit is your usable capacity, and capacity testing is how you measure it. Once you have a verified capacity number, you can calculate how much headroom exists above your projected peak, estimate what additional infrastructure might provide, and make a more informed decision about whether you’re ready for an upcoming launch or campaign.

What Is Capacity Testing?

Capacity testing finds the maximum load a system can handle while still meeting defined performance and error-rate targets. The result is typically expressed as a number of concurrent users, requests per second, or business transactions per hour.

The requirement to meet your targets is important. A system that stays online with 5,000 concurrent users but takes 30 seconds to serve each page doesn’t have a usable capacity of 5,000 users. For capacity planning purposes, your capacity is the highest load level where the system still provides an experience that meets your requirements.

Capacity Testing versus Stress Testing

Capacity testing and stress testing are both types of load testing, and they very often use the same scripts, bots, and test scenarios. Both ramp up the concurrent load, either gradually or in stages. A stress test might also use abrupt spikes. The big difference between capacity testing and stress testing is what you’re trying to learn from the test.

A stress test deliberately pushes beyond the breaking point so you can observe how the system fails and whether it recovers. A capacity test identifies the highest amount of load or traffic where performance remains acceptable.

In practice, a stepped test that continues beyond your acceptance threshold can sometimes address both questions: the last passing plateau is your measured capacity, and the later plateaus show how the system behaves under stress.

How to Run a Capacity Test

Define acceptance criteria first

Start by defining your acceptance criteria before you run the test. For example, you might require a 90th percentile response time under 2 seconds and an error rate under 1%. Agreeing on these thresholds in advance gives you an objective way to determine which load levels passed.

Use response time percentiles rather than relying only on a simple average. An average can hide slow outliers, while p90 or p95 shows the threshold experienced by most requests. Check out the FAQ on response time percentiles for more about interpreting these measurements.

Step the load up in plateaus

Next, increase the load in a series of plateaus. In a Loadster scenario, flexible load stages let a bot group follow a stair-step profile and remain at each load level for several minutes.

Holding the load steady is important because response times and throughput need time to stabilize. Caches might still be warming, connection pools might be filling, and autoscaling might still be reacting during the first part of each plateau.

As the test runs, watch the percentile response times and error charts for each plateau in the test report. Your capacity is the highest plateau where every criterion still passed.

Translate business traffic into concurrent users

Business requirements are often expressed in terms of transactions rather than concurrent users. A requirement like “6,000 orders per hour” is easy to obtain from the business side of your organization, but it doesn’t directly tell you how many bots to run in your load test because the answer depends on how long each scripted order takes, including realistic wait time between actions.

Our FAQ on calculating how many virtual users you need explains how to work backwards from your throughput target. You might still need a short calibration test to confirm that your scripts produce the expected transaction rate.

Using Your Capacity Numbers

One useful calculation is your headroom ratio: tested capacity divided by projected peak load. If your system handles 4,000 concurrent users within its performance targets and your projected peak is 2,000, you have 2x verified headroom. If the ratio is closer to 1.1x, a modest forecasting error or an unexpectedly successful campaign might push the system beyond its tested capacity. Running web applications with very little capacity headroom is risky.

Capacity per server, VM, or container is another useful planning estimate. If your current configuration handles 4,000 concurrent users on four application servers, 1,000 concurrent users per server is a reasonable starting assumption. However, extrapolating in the other direction is dangerous! Just because one server handles 1,000 concurrent users doesn’t mean four servers will handle 4,000 if there are other components that don’t scale out horizontally, such as a database shared by all the application servers.

Capacity rarely scales perfectly in a straight line because servers very often share a database, cache, or another constrained resource. A scalability test can verify how much capacity each additional server actually provides rather than relying on a risky assumption.

Finally, remember that a capacity test measures how a particular version of your application performs on a particular configuration. Significant code releases, architecture changes, and infrastructure changes can all move the number in either direction. Retest after such changes and record the date and configuration with each result.

Our guide to capacity planning for web applications explains how to incorporate repeated capacity test results into an ongoing planning process.

When to Run Capacity Tests

Capacity tests are especially useful before a predictable traffic event, such as a seasonal peak, product launch, or marketing campaign. Run the test far enough in advance to leave time for performance tuning, infrastructure changes, and a follow-up test if your headroom is lower than expected.

They can also support infrastructure and procurement decisions. A result such as “this configuration supported 4,000 concurrent users within our performance targets” is much more useful than estimating capacity from server specifications alone.

Conclusion

Capacity testing turns the question “can we handle the expected traffic?” into a measurable result. Define your acceptance criteria, increase load through a series of stable plateaus, and identify the highest level that still passes every requirement. You can then use that number to calculate headroom, evaluate scaling changes, and plan for future demand. Retest periodically so the result continues to reflect the system you’re actually running.

Frequently Asked Questions

What is capacity testing?

Capacity testing finds the maximum load a system can handle while still meeting its performance and error-rate targets. The output is a number, like how many concurrent users or requests per second you can serve acceptably. Once you have it, you know exactly how much headroom sits between your capacity and your expected peak traffic.

What is the difference between capacity testing and stress testing?

Both increase load in steps, but they stop at different places. A stress test deliberately pushes past the breaking point to observe how the system fails and recovers. A capacity test stops at the last load level where performance is still acceptable, because that level, not the level where things fall over, is your usable capacity.

How do you run a capacity test?

Define acceptance criteria first, like a 90th percentile response time under 2 seconds and errors under 1%. Then step the load up in plateaus, holding each level for several minutes so measurements stabilize. Your capacity is the highest plateau where every criterion still passed.

How much capacity headroom should a website have?

A 2x ratio of tested capacity to expected peak is a fairly common comfort level. If the ratio is closer to 1.1x, one good marketing email could put you over. The right answer depends on how spiky your traffic is and how expensive an outage would be compared to the cost of extra capacity.

How often should capacity be retested?

Treat the number as perishable. Every significant release can move it, sometimes dramatically, and usually nobody notices until traffic finds out for you. Retesting after major changes, and before any known traffic peak, keeps the number honest.

Next Steps: Ready to put a number on it? Try Load Testing with Loadster to build stepped load scenarios with per-plateau percentile metrics and find your true capacity.