loom-performance-testing
Performance Testing
Overview
Validate that a system meets latency, throughput, and stability targets under load, and locate the bottleneck when it doesn't. This file assumes you can write the test code; it focuses on the measurement traps that make load-test numbers lie and the decision criteria for tool/shape selection.
Core Concepts (read first — these are where numbers go wrong)
Open vs. closed workload models
The single most consequential choice. It determines what your numbers mean.
| Model | Load driver | Throughput is… | Overload behavior | Use for |
|---|---|---|---|---|
| Closed | Fixed VUs, each loops request→wait | Emergent (backpressure) | Self-throttles: slow server → fewer requests sent | Modeling a fixed client pool |
| Open | Fixed arrival rate (req/s) | Controlled (you set it) | Queue grows unbounded; latency explodes | Web traffic, finding breaking pt |
⚠ Closed models hide overload. With fixed VUs, when the server slows down each VU sends fewer requests, so offered load silently drops. You can't overwhelm the server past what its own latency allows — you measure a moving target, not capacity. Real internet traffic is open (users arrive independently of server health), so use an arrival-rate executor to find true breaking points.