Performance is the quality dimension concerned with latency, throughput and resource use under representative load. Most teams have monitoring; fewer have benchmarks in CI they trust.

What goes wrong

• Latency regressions on the hot path. A change increases p99 by 20 ms and nobody notices until customers do.
• Throughput collapse under load. The system handles 1× fine and falls over at 3×, which single-user load never shows.
• Resource leaks. Memory, file descriptors and connection pools creep linearly over hours or days, invisible in short tests.
• Accidental algorithmic complexity. Code runs in $O(n^2)$ where $O(n \log n)$ was intended, innocuous in tests with $n = 10$ and catastrophic at $n = 10^6$.
• Coordination overhead at scale. Lock contention, cache misses and garbage-collection pauses manifest only above some throughput.
• Tail latency. p50 meets the latency budget while p99.9 misses it. The mean is the wrong statistic for user-perceived latency.

The N+1 query

The database N+1 query issues one query per row instead of one for the whole set, so the number of queries climbs with the data instead of staying fixed. A test asserting on the query count catches it before production scale does, as does a profile of a realistic dataset. Tools that make that assertion are in algorithmic complexity testing.

What success looks like

• Tail-latency percentiles are named and tracked. Specific percentiles tied to user impact (p99, p99.9), not the mean.
• SLOs and error budgets are explicit. "p99 < 200 ms on the search endpoint, error budget X minutes per quarter."
• Regressions are caught in CI, not in production. A microbenchmark or pre-merge load test fails before merge.
• The benchmark setup is reproducible. Same hardware, same data, same warm-up; numbers don't move by 30% between runs.

Referenced by

• Quality dimensions · Quality dimensions
• Choosing methods · Overview