Build load-test scenarios from the work users and connected systems actually perform. Specify journey mix, arrivals, data sizes, background activity and the business outcomes being protected. A concurrent-user number on its own does not describe that workload or establish what a test should demonstrate.
The useful planning question is specific: can a particular workflow meet its agreed requirements under a stated pattern of demand? Making the pattern explicit helps a buyer review the proposed test before time is spent collecting results from an unrealistic model.
Define the business peak and the decision to test
Describe the operating situation that matters. A scheduled reporting period, a short burst of bookings and steady use throughout a working day pose different questions. Identify whether the purpose is to examine an expected peak, a growth assumption, a sudden increase or prolonged operation.
Microsoft's performance-testing guidance connects workload behaviour with defined performance targets. Use that principle to agree the business question and measurements. A vendor example should not become an unexplained response-time or capacity promise for another application.
Find the evidence behind the demand assumption. Existing service records can help, while a new product may need an explicitly labelled forecast. Record uncertainty and decide whether more than one scenario is needed to explore it. Do not present a guessed user count as measured customer demand.
Specify the test boundary too. Identify which application components and dependencies are included, which are simulated and which cannot safely receive test traffic. An excluded dependency limits the conclusion the exercise can support.
Describe journeys and data sizes
A useful journey represents work rather than a single URL. For a fictional operations portal, users might browse records, create invoices or upload supporting files. Each journey can have different request patterns, data volumes and downstream effects.
Use the system's software architecture choices to identify which dependencies a scenario must exercise.
Record the starting data as well as the actions. Searching a small demonstration dataset may behave differently from searching the intended record population. Upload size, result size, ownership filters and the variety of records can all change the work the system performs.
Include scheduled jobs, imports and other background activity that overlaps with user demand. Turning them off can make a test easier to run while removing the condition the business actually needs to understand. If a job is excluded, state the reason and the resulting limit.
Separate a realistic journey from an artificial repetition. A test that repeatedly requests one cached record can answer a narrow question, but it should not be described as representative of every customer action.
Choose arrivals or concurrency deliberately
Gatling's explanation of workload models distinguishes users arriving independently from a fixed population cycling through work. Those models can react differently when the application slows. Choose the one that represents the operating question rather than treating the two settings as interchangeable.
Arrival rate is not the same as active users
An arrival rate describes new work entering over time. Concurrency describes work or sessions active together. If tasks take longer, an unchanged arrival pattern can leave more activity in progress. The model needs a clear definition of what its “user”, “visit” or “transaction” represents.
Xceptance's load-model documentation also explains the distinction between user-count and arrival-rate approaches. Its example values are demonstrations of the tool, not recommended targets for your service.
Ask the performance engineer to explain how the chosen model handles waiting, pacing and completed journeys. A model that automatically reduces new work when the system slows can conceal a different business situation in which arrivals continue.
Build a transparent scenario mix
The following arithmetic uses invented assumptions to show how a workload worksheet can be reviewed. It is not an executed test or a capacity estimate for a real application.
- Assume the fictional portal receives 120 session starts per minute during its defined peak.
- If 30% start the invoice journey, the model needs 120 × 0.30 = 36 invoice journey starts per minute.
- If 15% start an upload journey, that produces 18 upload journey starts per minute under the same assumption.
- Record the remaining journey mix, upload-size assumptions and overlapping background activity separately.
These figures describe journey arrivals. They do not directly establish HTTP requests per second or the number of active users. Those depend on the actual steps, request counts, durations and pacing within each journey.
Write down the reason for every proportion. If the upload share is uncertain, a second scenario can explore a different mix. Keep the changed assumption visible so the comparison answers a clear question rather than producing two unexplained result sets.
A workload record should also identify data preparation and cleanup. Repeating a create operation can change the dataset as the test runs. Decide whether that reflects the intended workload and how test records remain controlled.
Agree measurements, targets and evidence
Choose measurements that show both demand and outcome. Useful evidence may include the achieved arrival rate, response-time distribution, errors, queue behaviour and the completion of the business operation. A system can respond quickly while returning the wrong result.
Include scaling and downstream limits from cloud application design when describing the test environment.
Targets must come from the actual service requirements and risk decisions. Avoid a universal claim that every application should support a particular number of users or complete every request within the same duration. Name the owner who can approve the chosen target and its trade-offs.
Record the application and environment versions, scenario configuration and important observations. If an external dependency was simulated, say so beside the conclusion. The result should be reproducible enough for a later change to be compared on a meaningful basis.
Review failed and degraded outcomes rather than reporting only a peak throughput figure. The business may need to understand whether work is rejected clearly, queued for later completion or left in an uncertain state.
Review a slow-upload variant of the fictional workload. Keep the stated arrival assumptions visible, change the file-size distribution and explain which other conditions remain the same. The resulting question is whether that workload changes queueing or completion behaviour; it is not a new claim about overall capacity. Record whether the upload journey includes transfer, processing and confirmation. Measuring only the first response can miss work that continues after the request returns, so the business outcome and its observation point need to be named together.
Review the workload before commissioning the test
Give the workload worksheet to both the business owner and performance engineer. One should be able to recognise the operating situation; the other should be able to explain how the model will exercise it. Resolve disagreements before interpreting a test result.
The specification should leave a clear trail from business demand to journeys, load model, data assumptions and acceptance evidence. That makes a later result useful for a release or capacity decision without overstating what was tested. It also keeps a software workload discussion distinct from unrelated physical proof-load testing.
Review the workload assumptions and performance testing scope with ZakCodeX before commissioning a test.
