Capacity planning becomes much more reliable when teams align around Requests Per Second (RPS) and latency assumptions.
Step 1: Define Target RPS by Scenario
Split RPS targets by scenario, not only by global average:
- steady-state traffic
- peak business hour
- burst campaigns
- failover/degraded mode
Start from an observed production window when possible. If the current peak is 800 RPS and the expected growth is 25%, the planning baseline is 1,000 RPS before resilience or campaign assumptions. Keep read, write and expensive endpoint mixes explicit; identical RPS values can create very different resource pressure.
Step 2: Convert RPS to Concurrency
concurrency ≈ RPS * latency_seconds
This quickly reveals thread-pool pressure, DB connection pressure, and queueing risk.
For example, 1,000 RPS at 250 ms average latency implies about 250 in-flight requests. At 800 ms it implies about 800. This is why an unchanged traffic target can still require a different pool or queue configuration after a latency regression.
Step 3: Estimate Instance Count with Safety Margin
instances_min = ceil(target_rps / per_instance_rps)
instances_recommended = ceil(instances_min * (1 + safety_margin_percent/100))
If one measured instance safely sustains 250 RPS, a 1,200 RPS target requires five instances. A 20% margin applied to that count recommends six. Keep redundancy separate: surviving a node or availability-zone loss is an architectural constraint, not the same thing as statistical headroom.
Step 4: Define Pass and Stop Conditions
Before running the test, write measurable criteria. A useful release gate includes achieved RPS, p95 and p99 latency, error rate, saturation indicators and a maximum queue depth. Also define a stop condition for dependency protection. Without these rules, teams tend to reinterpret a run after seeing the result.
Step 4: Validate with Real Signals
After tests or production windows, validate assumptions with:
- wait-event profile
- top SQL concentration
- CPU vs I/O breakdown
The Oracle AWR Report Analyzer helps convert AWR HTML into actionable diagnostics.
Use the exact test window when correlating data. An AWR interval that includes unrelated batch work or idle time can dilute the bottleneck that was active during the load plateau.
Recalibrate Instead of Extrapolating Blindly
Per-instance capacity is rarely linear forever. Repeat measurements near the intended operating range and after significant code, database or infrastructure changes. If six instances deliver less than six times the throughput of one, investigate shared dependencies, coordination overhead and load-balancer distribution before increasing the estimate.
Recommended Tool Flow
Using this flow gives a full loop: estimate, test, diagnose, and recalibrate.