“The system handles a thousand requests per second” sounds precise. Without a workload and a definition of success, it is an incomplete statement.
Which endpoints? Which users? Which data? For how long? With what error rate? A good load test starts by making those questions answerable.
Start with a hypothesis
Choose a question that can change an engineering decision. For example: does a slow dependency keep database connections occupied long enough to limit an otherwise healthy service?
That hypothesis gives the test a workload, measurements, and a reason to stop. It also makes the next step clearer: change one relevant condition and repeat a comparable experiment.
Name the arrival model
A fixed group of virtual users sends less work when responses become slower. A test driven by an arrival rate tries to schedule work independently of the response time. Those models answer different questions. The k6 explanation of open and closed models describes how response time and arrival behavior interact.
Neither model removes the need to inspect the load generator. Dropped iterations, resource limits, and insufficient virtual users can affect the experiment. The generator is part of the measured system.
Preserve the units
A journey may make several requests. A signup iteration may make one. Iterations per second and requests per second are different quantities, and their relationship belongs to the specific scenario.
The same applies to a user target. Daily active users, monthly active users, and registrations completed within a week imply different demand. Write the unit and timeframe next to the number so the next reader does not have to reconstruct your assumptions.
Capture the system that was actually running
Record the application revision, workload definition, data state, serving replicas, pool settings, and test duration. Capture the timeline of scaling and resource pressure, rather than just the final pod count.
Two runs with the same name can exercise different systems. A cold cache, a different replica count, or a changed dataset can explain a difference that would otherwise be attributed to a code change.
Treat overload as evidence
More offered work does not guarantee more completed work. Once a constraint is saturated, timeouts and retries may consume capacity while useful throughput falls.
Keep that part of the curve in the report. The last attempted tier is not automatically a demonstrated capacity ceiling. Separate the best observed result from a target that was actually sustained under the stated success criteria.
Finish with a decision
A useful report connects the finding to an action:
- What constraint did the evidence support?
- Which other explanation still needs to be ruled out?
- What change should the next experiment isolate?
- What conditions must remain comparable?
Missing evidence should remain unknown. A quiet dashboard or an absent demand estimate cannot establish that a system is ready.
The result of a load test is a better understanding of the system—and a defensible next engineering decision.