# Find the limits before your users do.

Performance & load testing

Measure response times, throughput and failure behaviour using realistic workloads and data volumes.

## Measure the workload you expect to serve

Illustrative workflow.

- Workload model: Request mix, concurrency and data size
- Test run: Latency distributions and resource behaviour
- Capacity decision: A bottleneck, an owner and a retest



## A useful load test begins with a workload model

Reproduce the important mix of users, requests and background work. Observe queues, dependencies and resource limits, then distinguish a code bottleneck from a capacity or data problem.

Illustrative scenario, not a customer case study.

An application owner wants alerts that reflect customer impact.

Define indicators around successful user tasks, response time and freshness. State the measurement window and exclusions explicitly so the operational team can interpret a breach.

Verification: Compare alerts with real incidents and record missed impact and unnecessary interruptions.

## A fast average can hide a slow customer experience

### Send the same request as fast as possible

The result may bear little relation to production traffic or the slow path customers actually encounter.

### Test representative demand and failure

Include realistic data, ramp-up, sustained load and dependency degradation alongside peak traffic.

## Reproduce demand before choosing capacity.

### Workload modelling

Represent concurrency, request mix, data size and burst patterns from the expected use of the system.

### Bottleneck diagnosis

Correlate response times with application, database and dependency behaviour under load.

### Capacity decisions

Record the tested limits and the signals that should trigger scaling or further investigation.

## What needs attention in your system?

Select the areas you want to discuss. The HTML page can download your selections.

- [ ] Workload modelling: Represent concurrency, request mix, data size and burst patterns from the expected use of the system.
- [ ] Bottleneck diagnosis: Correlate response times with application, database and dependency behaviour under load.
- [ ] Capacity decisions: Record the tested limits and the signals that should trigger scaling or further investigation.

## Which response-time metric should we use?

Review the distribution, especially the slower requests, rather than the average alone. Tie the target to a user task and define what traffic and failures it includes.