Workload Modelling · Performance Testing 101

Workload Modelling & Little's Law

Workload modelling converts business usage into a runnable performance test. Little's Law ties desired throughput, transaction time and think-time together to size the number of virtual users you must run.

01

Quick Definitions

Workload

The distribution of user activity over time across transactions — e.g., 40% search, 30% view, 20% cart, 10% checkout. Describes what users do and how often.

Workload Modelling

Converting business/production usage & NFRs into a runnable performance scenario — concurrent users, transaction mix, ramp-up, steady-state, pacing & think-times.

Iteration

One complete execution of a scripted business transaction — e.g., Login → Search → Add to Cart → Checkout.

Pacing

Average time between the start of two consecutive iterations.
Pacing = E2E Response Time + Think Time + Extra Wait

02

Little's Law

Classic Formula (Queueing Theory)
L = λ × W
L
Avg items in system → Concurrent Users
λ
Arrival rate → Iterations/sec (throughput)
W
Time in system → Pacing (seconds)
Mapped to Performance Testing
Users = Iterations/sec × Pacing
Iterations/sec = Users / Pacing  ·  Pacing = Users / Iterations/sec
03

Worked Examples

A

Calculate Users from Throughput

Target: 100 iter/sec
E2E Response: 1.2s
Think Time: 8.0s
Pacing = 1.2 + 8.0 = 9.2s
Users = 100 × 9.2 = 920
920 Virtual Users Needed
B

Calculate Throughput from Users

Users: 460
Pacing: 9.2s
Iterations/sec = 460 / 9.2 = 50
50 Iterations/sec Achieved
C

Setting Pacing for Frequency

Users: 300
Pacing: 30s (1 txn every 30s per user)
Iterations/sec = 300 / 30 = 10
10 Iterations/sec Achieved
04

Open vs Closed Workload Models

🔒

Closed Model

How
VU loops: think time + transaction + pacing. Little's Law applies directly.
Tool
JMeter Thread Group with loop count & real user pacing
Best For
Fixed logged-in users, session-based apps, licensing-limited clients, e-commerce browsing
🌐

Open Model

How
Users arrive as Poisson / fixed arrival rate. Specify throughput directly.
Tool
Constant Throughput Timer or Throughput Shaping Timer or Precise Throughput Timer for fixed iter/sec
Best For
Web traffic, APIs, synthetic arrival of new users, public-facing endpoints
05

Mapping to JMeter

Thread Group

Number of Threads (Users) = virtual users in the test

Think Time

Constant Timer or Gaussian Random Timer to mimic user pause between actions

Pacing

Timer after transaction or outer loop enforcing E2E + think + extra wait

Throughput Control

Constant Throughput Timer or Throughput Shaping Timer for open-model fixed iter/sec

Synchronizing Timer

Release many threads at once — perfect for spike & step-up tests

06

Common Pitfalls

1
Circular pacing definition — don't define pacing using itself. Pacing = E2E + think + extra_wait.
2
Ignoring E2E variability — Little's Law uses average W. Account for higher percentiles (P90/P95/P99) when sizing.
3
Generator bottlenecks — if load generators are overloaded, measured throughput is wrong. Always monitor generator CPU/RAM/network.
4
Cache effects — warm caches reduce E2E; cold caches increase it. Use realistic cache warm-up before measurement.
5
Mix vs single transaction — multiple transactions with different E2E times? Compute effective pacing per transaction or sum arrival rates.
6
Misinterpreting think time — think time is user idle time, not a way to mask slow servers.
7
Open vs Closed confusion — ensure the tool setting and business expectation match the chosen model.
07

Workload Modelling Steps

Collect Data

Production logs, analytics, BA estimates, peak & average traffic, transaction mix

Decide Model

Open (requests/sec) or Closed (concurrent users) based on real traffic

Measure Baseline

Get E2E response times per transaction under low load (avg + percentiles)

Compute Pacing

Pacing = avg E2E + avg think time + extra wait

Apply Little's Law

Calculate required users or iterations/sec from your inputs

Design Profile

Ramp-up (10 min) → Steady state (60 min) → Ramp-down (10 min)

Implement in Tool

Threads, timers, throughput controllers, correlation, parameterization

Warm Up

Preload caches & DB connection pools before measuring steady state

Run & Validate

Actual throughput ≈ planned? If not, diagnose generators or pacing issues

Analyze & Iterate

Check resource metrics, percentiles, bottlenecks. Tune & repeat.