Requirements & Workload Modelling

The workload model is the single most important artefact in a performance test. If it doesn't represent reality, nothing downstream — however well executed — matters.

Defining objectives

We translate business concerns into measurable criteria. "The site must be fast on launch day" becomes: at 5,000 concurrent sessions with the launch-day transaction mix, p95 page response ≤ 800 ms, p99 ≤ 2 s, error rate < 0.1%, for a sustained 2-hour window. Each objective gets an owner, a priority and an agreed measurement method.

Building the workload model

A complete model specifies, for each business transaction: its share of total traffic, its arrival rate at peak, the concurrency it generates, think-time distributions, and the data variety it touches. Sources, in order of preference:

Production analytics (APM, web analytics, access logs) give real transaction mixes and arrival patterns. Business forecasts scale those patterns for growth or events. Structured interviews fill gaps for new systems with no history, cross-checked against comparable systems.

Workload model extract — retail peak hour
  transaction          share    rate (tps)   concurrency
  browse catalogue     62%        260           3,900
  search               18%         75           1,100
  add to cart           9%         38             420
  checkout              6%         25             310
  account/other         5%         21             190
  totals               100%       419           5,920
  arrival pattern: Poisson, hourly seasonality applied
  think time: lognormal μ=12s σ=8s (from analytics)

Concurrency vs throughput

Stakeholders usually talk in "concurrent users"; systems experience arrival rates. We model both and keep the relationship explicit via Little's Law: concurrency = throughput × (response time + think time). Confusing the two is the most common workload-modelling error, and it can change the effective load by an order of magnitude.

Phase outputs

A written test plan containing objectives with pass criteria, the workload model with data sources documented, in-scope and out-of-scope transactions, environment requirements, and a risk register. This document is reviewed and signed off before scripting begins.