Before you run load tests, estimate infrastructure requirements to avoid false negatives caused by under-provisioning.
Simple Sizing Flow
- Estimate target RPS for the scenario.
- Determine per-instance safe throughput.
- Add safety margin (20% to 40% is common).
- Validate burst behavior separately.
Use a measured per-instance value from a representative workload. A benchmark that exercises only cached reads should not size a production mix that includes writes, authentication and database joins.
Instance Estimate
instances_min = ceil(target_rps / per_instance_rps)
instances_recommended = ceil(instances_min * (1 + safety_margin_percent/100))
Worked example
A target of 1,200 RPS and a measured safe capacity of 250 RPS per instance yields five minimum instances. Applying 20% headroom yields six recommended instances. If the test must continue after one instance fails, validate the target with only five available; do not assume the headroom automatically covers resilience.
Check Shared Constraints
Application instances are only one layer. Estimate the connection demand and capacity of the database, cache, message broker and third-party APIs. Confirm operating-system file descriptors, ephemeral ports and load-generator capacity. When a shared dependency saturates first, adding application instances can increase contention instead of throughput.
Separate Steady State from Bursts
Run long enough to expose garbage collection, cache churn, autoscaling and pool behavior. Then test a short burst separately. Record both the peak and the recovery time: a service that returns to normal slowly can remain risky even if it survives the spike.
Checklist Before Test Day
- Autoscaling thresholds configured and tested.
- Database pool limits reviewed.
- Upstream/downstream dependencies benchmarked.
- Error budget and rollback criteria defined.
Capture the exact build, configuration, dataset and infrastructure shape with the result. Define success using achieved RPS, p95/p99 latency, error rate and saturation thresholds. This makes the next run comparable and prevents a peak-throughput number from being presented without its operating conditions.
Limits
This arithmetic assumes capacity scales roughly with instance count near the measured point. Locks, database limits, network bandwidth, coordination and load imbalance make scaling nonlinear. Use sizing to provision the experiment, then replace assumptions with observed safe throughput.
Practical Tools
Start with Infrastructure Sizing Calculator, then validate edge cases with Burst Traffic Calculator.