How do you design a realistic workload model for a performance test?

A performance test is only as useful as its workload model. Hammering one endpoint with 1,000 virtual users and no think time produces numbers, but not answers about production.

1. Start from production data

• Volume: requests per second or transactions per hour at normal and peak times, from access logs, APM or analytics. Identify the peak hour and the peak minute.
• Journeys: what users actually do (browse, search, add to cart, checkout) and the proportions, for example 60% browse, 25% search, 10% cart, 5% checkout.
• Behaviour: session length, think time between actions, how many items per order, logged-in vs anonymous.
• Growth: business forecasts or events (sales, campaigns) to set peak and headroom scenarios, such as 2x current peak.

For a new system without production data, use business estimates, state the assumptions explicitly, and revisit them after launch.

2. Choose open or closed

This is the point many candidates miss.

• Closed model: a fixed number of virtual users loop through a journey. A new iteration starts only when the previous one finishes. If the system slows down, the load generator automatically sends fewer requests. That under-reports the impact of slowness for public internet traffic, where new users keep arriving regardless.
• Open model: requests or iterations arrive at a fixed rate, independent of response time. When the system slows, work queues up, as it would in reality. In k6 this is the constant-arrival-rate or ramping-arrival-rate executor; in JMeter, a throughput-shaping approach (for example the Constant Throughput Timer, or the open model thread group added in JMeter 5.5).

Rule of thumb: public websites and APIs are closer to open; internal tools with a fixed set of users, or batch workers pulling from a queue, are closer to closed.

3. Think time and pacing

Real users pause. Without think time, 100 virtual users generate far more load than 100 real users, and the concurrency numbers become meaningless. Use randomised think time based on observed behaviour. In arrival-rate models, the rate itself controls load and think time mostly shapes sessions.

4. Test data

• Enough unique users, products and search terms, otherwise caches make everything look fast.
• Realistic data volumes in the database; a query that is fast on 1,000 rows may not be on 50 million.
• Data that is consumed (orders, registrations) needs a refresh strategy between runs.

5. Targets and scenarios

Agree acceptance criteria before running: per-journey p95/p99, error rate, throughput, and resource limits. Then define scenarios: baseline load, peak, stress beyond peak, soak, and any event-specific spike.

Common mistakes

• Using concurrent users as the only load metric without relating it to requests per second.
• Testing one endpoint in isolation and calling it a capacity result.
• Small, repeated test data that is served from cache.
• No agreed targets, so every result is “it depends”.

What interviewers look for

• Data-driven workload with a transaction mix.
• A clear explanation of open vs closed models and when each applies.
• Think time, data variety and agreed targets.