Workload representativeness and trace provenance
Connect a performance claim to its target workload through explicit sampling, trace transformations, and population weights.
On this page
The question for today
What you’ll understand
- Separate collected trace composition from the intended workload population.
- Document how collection and replay transform observable behavior.
- Compute a weighted cost without averaging unrelated speedup ratios.
A trace is a sample produced by an observation process, not a transparent copy of all production demand. Collection windows, instrumentation, privacy filters, sampling, and failures decide which events survive. Replaying the survivors can change concurrency and feedback again. A credible study describes those transformations and identifies the population its measurements represent. A benchmark can be perfectly repeatable yet answer a narrow question about an unrepresentative slice of activity.
Define the population and preserve the trace lineage
Start with the decision population: tenants, request classes, time periods, regions, data sizes, and arrival conditions. Record collection location, clock source, missing intervals, sample probabilities when known, and the software schema that assigned meaning to each field. Preserve immutable raw-trace identifiers and a transformation manifest for filtering, anonymization, deduplication, and unit conversion. A privacy-preserving transformation may intentionally remove correlations that matter to cache locality or routing. Document that loss instead of calling the transformed trace behaviorally identical.
Compare collected composition with the target rather than assuming a large file is representative. Oversampling rare slow operations can improve diagnostic coverage but distort an unweighted mean. A workload with many cheap lookups and occasional expensive scans needs stated population weights if the claim concerns mean request cost. Compute weighted costs in their original units before forming an overall ratio. The resulting aggregate does not replace per-class results, because a favorable mean can conceal a regression in a tenant or a latency-sensitive operation.
Replay has an execution model of its own
An open-loop replay schedules arrivals from the trace independently of response completion. A closed-loop client submits subsequent work after earlier responses, possibly with think time. These designs can expose very different overload behavior. Dropping arrivals that cannot be issued on time may hide queueing, while sending them all in a burst creates a different workload. Preserve intended and actual issue times, completion times, errors, and admission decisions. Include the load generator in capacity checks so a client bottleneck is not mistaken for server saturation.
Time compression changes more than the label on an axis. Uniformly dividing interarrival gaps by a factor c multiplies the intended average arrival rate by c for the same event count and proportionally shortened observation interval. It need not preserve cache residency, background maintenance overlap, or user adaptation. Synthetic scaling should also state whether keys, object sizes, tenant counts, and temporal correlations change. A response-dependent production trace cannot generally be replayed under a different system while retaining all feedback relationships.
Audit omitted behavior and test trace-sensitive mechanisms
List information that is unavailable: requests rejected before instrumentation, cache state before collection, traffic from excluded tenants, or deleted identifiers. Separate a convenience sample from a probabilistic sample; unknown selection probabilities can prevent justified population reweighting. Use multiple collection windows and sensitivity analyses to show how conclusions depend on composition. When a representative proprietary trace cannot be published, release a permitted surrogate and explain which properties it matches and which conclusions an independent investigator cannot reproduce with it.
The cache instrument shows why stream structure matters even with the same request count. Reset, set both C=4 and s=4, predict four misses and thirteen hits after one Step, then Step once. Separately Reset, set both C=4 and s=1, predict seventeen misses after one Step, then Step once. Both runs start empty and evaluate seventeen requests to address (i·s) mod 16. This fully associative LRU toy isolates a synthetic locality difference; it is not a production trace, processor cache benchmark, or validation of a real replay generator.
Work it through
A fast lookup path can lose on the target mixture
Suppose separate compatible measurements give baseline means of 2 ms for lookups and 80 ms for scans. A candidate gives 1 ms and 100 ms respectively. For a target of 90% lookups and 10% scans, assume these class means apply under that mix.
The baseline target mean is 0.9×2+0.1×80=9.8 ms. An all-lookup benchmark would instead report 2 ms and omit the costly class entirely.
The candidate target mean is 0.9×1+0.1×100=10.9 ms. Its lookup path is twice as fast, but the scan regression contributes two additional milliseconds per target request before the lookup saving.
The candidate mean is (10.9−9.8)/9.8≈11.22% higher. The aggregate baseline/candidate time ratio is about 0.899, so a twofold claim from lookup-only measurements does not describe this target population.
State the target weights, class costs, and execution assumptions. Do not average per-class speedup ratios into a population latency claim.
The living notebook
Explore the model
Interactive lab · cache
A request count does not describe a workload
Reset, set both C=4 and s=4, predict four misses and thirteen hits after one Step, then Step once. Separately Reset, set both C=4 and s=1, predict seventeen misses after one Step, then Step once. The fixed sixteen-address LRU stream is a locality illustration, not a trace validator.
- Hits / requests
- 0 / 16
- Hit rate
- 0%
- Address-stream period
- 16 addresses
A fully associative LRU cache starts empty and requests address (i·s) mod 16. Hits move an address to the newest position; misses evict the oldest when full. Playback starts with 16 requests and adds two per second, capped at 4096 explicitly simulated requests. This toy stream is not a processor-cache benchmark. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forPreserve the workload properties that drive the proposed mechanism.
Pause & reason
Check your understanding
Your turn
Try it yourself
Using the same class means, change the target to 80% lookups and 20% scans. Compute both weighted means and the candidate’s percentage increase.
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Weight the measured millisecond costs first; form a relative comparison only afterward.
Compare with the solution
The baseline mean is 0.8×2+0.2×80=17.6 ms. The candidate mean is 0.8×1+0.2×100=20.8 ms. The increase is 3.2/17.6≈18.18%. This calculation assumes the class means remain applicable at the new mix; an actual load-dependent system may require another run.
Keep the idea
Take it with you
- A trace’s collection and transformation history bounds what it represents.
- Weight compatible costs for the target population before computing aggregate ratios.
- Replay timing, client feedback, and locality are part of the workload contract.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.