openskills.info
Course catalog
Course Preview

Performance Testing

Performance testing measures how quickly, reliably, and efficiently a system works under defined conditions. It applies controlled work, observes user-facing results and resource use, and compares the evidence with explicit targets.

itObservability and performance

Don't Panic — Performance Testing

Every performance test is trying to answer one nervous question: when the real users arrive, does the thing hold up? The honest answer is never a clean "yes". It is "under these conditions, measured this way, the system met these targets". This tab is about why that sentence needs so many clauses.

Start with what a performance test is not. It is not switching on a lot of traffic and watching a dashboard go red. It is an experiment: you decide the question first, such as whether a release meets a latency target or whether a service survives the forecast, and only then build conditions that let the numbers answer it.

Those conditions have four parts. The workload model is the operations, data, timing, and concurrency that stand in for real demand. The load generators are the machines that produce it. The system under test is your application plus every dependency inside the boundary you drew. Measurement is the clocks and counters on both sides, and both sides matter: if a generator runs out of processor or sockets, the result describes the generator, not the server.

The idea that trips people up is that a count of users is not a workload. Five hundred people acting once an hour and five hundred acting once a minute are very different loads. What matters is throughput, the work completed per second, and concurrency, the work in flight at once. Those are not the same number, and confusing them is how a test misses its target by an order of magnitude.

There are two ways to drive the load. A closed model keeps a fixed set of virtual users who wait for each response before continuing; when the system slows, they slow down with it, which quietly hides the pressure you were trying to create.

An open model schedules arrivals regardless of what came back, so when the system falls behind, queues grow, exactly as they would during a real incident. Choosing the wrong one is choosing whether your test can see the problem at all.

When you read results, respect the distribution. An average folds the fast and the slow into one number that describes neither. A 95th percentile of 400 milliseconds means 95 percent of responses were that quick or quicker; it says nothing about the slowest five percent, and those are the ones that wake someone up.

Then the humble part. A performance test supports a claim only for the workload, data, build, and hardware you actually tested. It does not prove behaviour at twice the scale, or under a dependency failure nobody injected. Recovery counts too: whether queues drain and instances come back once the load stops is part of the result, not an afterthought.

Where to go next: the Intro builds this experiment idea slowly and hands you the vocabulary. The Cheatsheet is the reference to keep open while you design a run. Field Notes is where the expensive lessons live, the ones that normally cost real traffic to learn.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources