Workload Modelling in Software Performance Testing

Your online store handles a busy afternoon without any trouble. During a weekend promotion, customers start reporting delayed payments and frozen carts. The load test passed last week - so what went wrong?

The test may have generated plenty of requests without matching real customer activity. Workload modelling helps you describe what users actually do and how frequently those actions reach your systems.

What Is Workload Modelling?

Workload modelling is the process of building a traffic pattern from real application usage. You decide which operations happen, how many users perform them and when demand increases. This model guides performance testing by giving the simulated activity a realistic structure.

Consider an online shop where most visitors browse products and fewer complete purchases. Sending thousands of login requests would miss the database pressure caused by searches and checkout transactions.

Start With Evidence From Your Application

You can begin with API gateway logs, analytics reports and application monitoring dashboards. Collect data from normal days and from your busiest trading periods. Separate customer actions from automated crawlers and internal monitoring calls where possible.

Capture the following details before choosing your load-generator settings:

• Request volume: Record incoming requests per minute during busy periods.

• User journeys: Identify the steps involved in browsing or purchasing.

• Traffic distribution: Measure how frequently each endpoint receives requests.

• Peak periods: Compare ordinary demand with promotions or scheduled events.

• Response times: Record median and 95th-percentile results for important operations.

• Failure patterns: Count timeouts, rejected requests, and client retries.

Do not confuse visits with requests reaching your application servers. The 2025 HTTP Archive Web Almanac reported medians of 72 requests per mobile page and 77 per desktop page. Those figures include page resources and caching can prevent many from reaching your backend. Your own server logs provide a better starting point for actual API demand.

Turn Traffic Numbers Into a Workload

Suppose your analytics show 600 customer journeys beginning every minute during peak trading. Each journey generates four backend requests on average - giving you 2,400 requests per minute. Your estimated starting demand is therefore 40 backend requests per second.

You can express the calculation in one simple line:

Requests per second = journeys per second × average backend requests per journey

The example gives 10 journeys per second and 40 backend requests per second. These figures are illustrative and should be replaced with your measured traffic. A promotional peak reaching twice that level would require another scenario with higher arrivals.

Next, split the journeys according to actual customer behavior:

• 60% browse: Search the catalogue and open product pages.

• 25% manage carts: Add products and change their quantities.

• 15% check out: Confirm addresses and submit orders.

Treat this split as an example rather than a universal shopping pattern. Each journey can make a different number of API calls. You should calculate the weighted request rate after defining their individual steps.

Choose Between Virtual Users and Arrival Rates

A virtual user represents a simulated client following your test instructions. A closed workload model keeps a set number of these clients active. Each client completes its journey before beginning another one.

An open workload model starts new journeys at a chosen rate. New arrivals continue even when earlier requests take longer to complete. Grafana's k6 documentation explains why these models produce different results when servers slow down.

Use a fixed user population when studying how simultaneous sessions behave. Choose arrival-rate scheduling when recorded traffic shows a predictable flow of incoming requests. An open model can reveal growing queues that closed tests may hide.

Remember that simultaneous sessions and requests per second measure different things. If 10 journeys begin each second and last 12 seconds on average, roughly 120 journeys overlap. This estimate assumes stable traffic and includes any waiting time within those journeys.

Include Pauses and Changes in Demand

Real customers do not submit every request without stopping. People read descriptions and reconsider quantities before continuing their journey. Your scripts should include pauses where the recorded behavior supports them.

Build your plan around these five separate traffic conditions:

• Warm-up: Start slowly to check scripts and application readiness.

• Normal load: Hold traffic near the busiest measured weekday level.

• Peak load: Increase arrivals to the recorded promotional level.

• Spike: Introduce a sudden increase for a limited period.

• Endurance: Maintain expected demand long enough to reveal resource problems.

Watch connection pools and database queues throughout the test. Set load limits and monitoring alerts before using a production environment.

Use Test Data That Represents Real Transactions

Repeating one account or product identifier can produce misleading results. Cached product details may answer quickly while purchase updates compete for the same record. Use varied accounts and inventory records from an approved test dataset.

Give each checkout journey suitable order data and payment sandbox credentials. Clean up generated orders after each run when your environment permits it. Include failed logins and invalid requests only when production data supports their expected frequency.

Your geographic assumptions deserve attention when applications serve several markets. Test traffic from relevant regions and record the network conditions separately. Avoid treating slow international connections as proof of a database bottleneck.

Measure Results Against Clear Limits

An average response time can hide slow experiences during busy periods. Review response-time percentiles alongside failure rates and completed transactions. Grafana's k6 threshold guidance explains how to define pass-or-fail limits for these measurements.

For example, your team might require 95% of checkout API requests to finish within 500 milliseconds. You could also set a maximum error rate of 1%. These are example targets, not recommended limits for every application.

Check CPU usage, memory growth, database locks, and queue depth during failures. Compare results against the same test setup after each major release.

Keep Your Model Updated

Customer behavior changes as your application adds features or reaches new markets. Refresh baseline numbers before a major sale or infrastructure change.

Qalified.com describes a methodology built around realistic user scenarios, parameterized scripts, and system monitoring. This provides an example of how workload analysis can connect planning with test execution.

Conclusion

Useful workload models begin with observed behavior rather than guessed user counts. Your model should explain incoming traffic, customer journeys, timing and changing demand. Use the same evidence to investigate failures before your next release.

by T.Smalsar (an Handwiki editor)