Load Testing
Load testing answers the most fundamental question in performance engineering: does the system meet its service-level objectives under realistic production load?
What it is
A load test applies a workload that mirrors expected production traffic — the same transaction mix, arrival rates, think times and data variety — and measures whether response times, error rates and throughput stay within agreed targets. It is a validation exercise: pass/fail against explicit criteria, not an open-ended poke at the system.
Our approach
We start with a workload model built from production analytics: which transactions occur, at what rates, with what concurrency. A typical profile ramps virtual users to the target over 15–30 minutes, sustains the plateau for at least 60 minutes, then ramps down — long enough for caches to warm, JIT compilation to settle and connection pools to reach steady state.
Profile: business-peak load test
ramp-up : 0 → 2,500 VU over 20 min
plateau : 2,500 VU for 60 min (≈ 420 req/s)
ramp-down : 2,500 → 0 VU over 5 min
pass criteria:
p95 latency ≤ 500 ms (all transactions)
p99 latency ≤ 1,200 ms
error rate < 0.1%
no resource > 75% sustained utilisation
What we measure
Latency percentiles (p50/p90/p95/p99 — never averages alone), throughput in requests and business transactions per second, error rates by type, and server-side resource utilisation: CPU, memory, GC behaviour, connection pools, thread pools, database wait events and queue depths. See Key Performance Metrics for why percentiles matter.
Typical findings
Undersized connection pools that throttle throughput well below infrastructure capacity; N+1 query patterns invisible at functional-test volumes; cache misconfiguration; chatty service-to-service calls; and database locks that only contend under concurrency.
Deliverables
Test plan and workload model, version-controlled scripts, full results dataset, and a report stating clearly whether the system passed its criteria — and if not, why, with evidence.