You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
152506: asim: measure thrashing r=tbg a=tbg
This commit adds a thrashing benchmark to each stat output. "Thrashing" can be
measured in many ways, but here we measure, for each per-store timeseries, a
trend-discounting total variation. Roughly speaking, this computes the upward and
downward total variation separately, then interpolates between the minimum of both
and their sum. When one direction clearly dominates the other, it biases toward the
minimum. When up and down are roughly comparable, it returns something approximating
the sum - which is the "vanilla" total variation. In other words, thrashing is low when the
time series has a clear trend, and it is high when the series moves around but doesn't
seem to be trending anywhere.
When displaying the resulting value, we additionally normalize (divide by) the "range" of values
seen (i.e. the max minus the min), and print the result as a percentage.
For
example, the time series [0, 1, 0, 1, 0] has an upward and downward variation of 2. Neither dominates, so the trend-adjusted total variation equals the total variation 4. The values are all in `[0,1]`, so the range is 1. The resulting trend-discounting total variation percentage would be `tdtv/range = 4/1 = 400%`.
Intuitively, this means that the time series "sweeps" across the range
four times. Additional oscillations would drive this number up further.
In contast, the series `[0, 1, 0, 10, 100, 1000]` is mostly increasing, with the exception of the small downward jump between the second and third datapoints. Consequently, the trend-discounting total variation would (roughly) equal only the downward total variation, which equals 1. The range is 1000, so the percentage in this case would be `1/1000 = 0.1%`.
When printing the thrashing across a set of stores (but for a fixed stat),
instead of computing the range within each store's time series, we compute it
across the entire set. This makes it more likely that we discover the "true
range".
All of this can be made arbitrarily more complicated (and additional
normalization by the number of runs or ticks may be appropriate for some use
cases), but this should be a good start.
Epic: CRDB-49117
Release note: none
Co-authored-by: Tobias Grieger <[email protected]>
0 commit comments