research30 min studyLesson 982 in Engineering

Workload representativeness and trace provenance

Connect a performance claim to its target workload through explicit sampling, trace transformations, and population weights.

On this page

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.

μtarget=∑j=1Jwjμj,wj≥0,∑j=1Jwj=1\mu_{\rm target}=\sum_{j=1}^{J}w_j\mu_j,\qquad w_j\ge0,\quad\sum_{j=1}^{J}w_j=1
The weights are target request proportions and μ_j is a class-specific mean cost in milliseconds under a compatible execution regime. This mixture identity does not make a class latency independent of load; changing the mix may require rerunning the system.↔ Scroll wide equations horizontally.

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.

Δtireplay=Δtitracec,λintendedreplay=cλtrace,c>0\Delta t_i^{\rm replay}=\frac{\Delta t_i^{\rm trace}}{c},\qquad \lambda_{\rm intended}^{\rm replay}=c\lambda^{\rm trace},\quad c>0
Time gaps are seconds and rates are requests per second. The rate relation assumes the same events over a uniformly compressed interval and describes intended issuance, not achieved server throughput or preservation of closed-loop feedback.↔ Scroll wide equations horizontally.

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.

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.

  1. 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.

  2. 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.

  3. 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.

The result

State the target weights, class costs, and execution assumptions. Do not average per-class speedup ratios into a population latency claim.

Explore the model

Interactive lab

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.

A request count does not describe a workloadA 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. Current readings: Hits / requests: 0 / 16; Hit rate: 0%; Address-stream period: 16 addresses. All parameters are adjustable with the labeled controls below.Fully associative LRU cache after 16 deterministic requests: 0 hits and 16 misses.Most recent 16 requestsaddress = i × 3 mod 160M3M6M9M12M15M2M5M8M11M14M1M4M7M10M13MCurrent cache order · oldest → newest471013Latest address 13 · miss: inserted as newestToy address stream · period 16 · starts empty
Cached addressMiss / evictionMost recent request
Hits / requests
0 / 16
Hit rate
0%
Address-stream period
16 addresses
t = 0 s

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.

Check your understanding

What is needed to interpret an aggregate mean from a trace that oversamples expensive scans?

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.

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.