Load Testing
debt(d9/e5/b5/t5)
Closest to 'silent in production until users hit it' (d9). The detection_hints note 'No load test results in project history; performance only measured in production; unknown capacity limits' — the absence of load testing is invisible until real users trigger failures like 504 errors at peak traffic. None of the tools listed (k6, locust, gatling, jmeter, wrk) run automatically in a standard CI pipeline unless explicitly configured, so the gap goes completely unnoticed.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix suggests running k6 or Locust against staging, which sounds simple, but common_mistakes reveal the real remediation: setting up a production-like environment with realistic data volumes, fixing N+1 queries discovered under load, adjusting connection pool sizes, and resolving p99 latency issues. These fixes span infrastructure configuration, query optimisation, and application code — not a single-line patch.
Closest to 'persistent productivity tax' (b5). Applies to web and API contexts broadly. The ongoing burden is that without load testing integrated into the release process, every major release carries hidden capacity risk. Teams must maintain staging environments with realistic data, configure load test tooling, and interpret results — this is a recurring cost across many work streams (development, QA, DevOps) rather than a localised one-component tax.
Closest to 'notable trap (a documented gotcha most devs eventually learn)' (t5). The misconception field directly states the trap: developers believe load testing only matters for large applications, when in fact a single misconfigured query can fail a small app under tens of concurrent users. This is a well-known gotcha in the performance community but routinely surprises intermediate developers who equate scale with necessity.
Also Known As
TL;DR
Explanation
Load testing generates concurrent requests to simulate production traffic levels. Types: load testing (expected peak), stress testing (find breaking point), soak testing (sustained load over hours), spike testing (sudden burst). Tools include k6 (JavaScript DSL), JMeter (Java GUI), and Locust (Python). Key metrics: requests per second, p95/p99 latency, error rate, and resource saturation. Results reveal N+1 queries, missing indexes, and connection pool exhaustion that unit tests cannot find.
Diagram
flowchart TD
TOOL[k6 Gatling JMeter] --> SCENARIO[Test Scenario<br/>virtual users + ramp up]
SCENARIO --> TARGET[Target system]
TARGET --> METRICS[Collect metrics]
subgraph Watch
RESP[Response time p50 p95 p99]
TPUT[Throughput req/s]
ERR[Error rate pct]
end
METRICS --> RESP & TPUT & ERR
subgraph Test_Types
LOAD[Load test<br/>normal traffic]
STRESS[Stress test<br/>beyond capacity]
SPIKE[Spike test<br/>sudden burst]
SOAK[Soak test<br/>extended duration]
end
style TOOL fill:#1f6feb,color:#fff
style STRESS fill:#f85149,color:#fff
style LOAD fill:#238636,color:#fff
style SPIKE fill:#d29922,color:#fff
Common Misconception
Why It Matters
Common Mistakes
- Not testing against a production-like environment with realistic data volumes.
- Only measuring average response time — p99 latency reveals the worst user experience.
- Not monitoring database query counts during load tests — N+1 patterns become obvious at scale.
- Running load tests from a single machine — saturates the load generator, not the application server.
Code Examples
# No load test — assuming dev performance scales:
# Dev: 10ms response, 1 user
# Production launch: 200 concurrent users
# Result: DB connection pool exhausted (max 10 connections)
# All requests fail with 'Too many connections' — avoidable# k6 load test — ramping up to 200 concurrent users:
import http from 'k6/http';
import { check } from 'k6';
export let options = {
stages: [
{ duration: '30s', target: 50 },
{ duration: '1m', target: 200 },
{ duration: '30s', target: 0 },
]
};
export default function() {
let res = http.get('https://staging.example.com/api/users');
check(res, { 'status 200': r => r.status === 200 });
}