-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: merge gauges properly and avoid dropping existing points #444
Conversation
} | ||
} | ||
(Self::Gauge(a), Self::Gauge(b)) => *a = b, | ||
(Self::Gauge(a), Self::Gauge(b)) => a.merge(b, merge_scalar_latest), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the fix, basically. Right here. This one lil guy.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Regression Detector (DogStatsD)Regression Detector ResultsRun ID: a37173bd-7754-4503-9ef7-af66b2e5a1c7 Baseline: 7.62.0-rc.8 Optimization Goals: ✅ No significant changes detected
|
perf | experiment | goal | Δ mean % | Δ mean % CI | trials | links |
---|---|---|---|---|---|---|
➖ | dsd_uds_100mb_3k_contexts_distributions_only | memory utilization | +1.48 | [+1.28, +1.69] | 1 | |
➖ | quality_gates_idle_rss | memory utilization | +0.42 | [+0.31, +0.52] | 1 | |
➖ | dsd_uds_10mb_3k_contexts | ingress throughput | +0.00 | [-0.00, +0.00] | 1 | |
➖ | dsd_uds_1mb_3k_contexts | ingress throughput | +0.00 | [-0.00, +0.00] | 1 | |
➖ | dsd_uds_512kb_3k_contexts | ingress throughput | +0.00 | [-0.01, +0.01] | 1 | |
➖ | dsd_uds_1mb_50k_contexts | ingress throughput | +0.00 | [-0.00, +0.00] | 1 | |
➖ | dsd_uds_100mb_250k_contexts | ingress throughput | -0.00 | [-0.00, +0.00] | 1 | |
➖ | dsd_uds_1mb_3k_contexts_dualship | ingress throughput | -0.00 | [-0.00, +0.00] | 1 | |
➖ | dsd_uds_1mb_50k_contexts_memlimit | ingress throughput | -0.00 | [-0.00, +0.00] | 1 | |
➖ | dsd_uds_100mb_3k_contexts | ingress throughput | -0.00 | [-0.05, +0.04] | 1 | |
➖ | dsd_uds_40mb_12k_contexts_40_senders | ingress throughput | -0.00 | [-0.00, +0.00] | 1 | |
➖ | dsd_uds_500mb_3k_contexts | ingress throughput | -0.27 | [-0.30, -0.24] | 1 |
Bounds Checks: ❌ Failed
perf | experiment | bounds_check_name | replicates_passed | links |
---|---|---|---|---|
❌ | quality_gates_idle_rss | memory_usage | 0/10 |
Explanation
Confidence level: 90.00%
Effect size tolerance: |Δ mean %| ≥ 5.00%
Performance changes are noted in the perf column of each table:
- ✅ = significantly better comparison variant performance
- ❌ = significantly worse comparison variant performance
- ➖ = no significant change in performance
A regression test is an A/B test of target performance in a repeatable rig, where "performance" is measured as "comparison variant minus baseline variant" for an optimization goal (e.g., ingress throughput). Due to intrinsic variability in measuring that goal, we can only estimate its mean value for each experiment; we report uncertainty in that value as a 90.00% confidence interval denoted "Δ mean % CI".
For each experiment, we decide whether a change in performance is a "regression" -- a change worth investigating further -- if all of the following criteria are true:
-
Its estimated |Δ mean %| ≥ 5.00%, indicating the change is big enough to merit a closer look.
-
Its 90.00% confidence interval "Δ mean % CI" does not contain zero, indicating that if our statistical model is accurate, there is at least a 90.00% chance there is a difference in performance between baseline and comparison variants.
-
Its configuration does not mark it "erratic".
Regression Detector (Saluki)Regression Detector ResultsRun ID: bb0a943d-79e1-47f1-9d95-58230bc95bbd Baseline: 3576732 ❌ Experiments with missing or malformed dataThis is a critical error. No usable optimization goal data was produced by the listed experiments. This may be a result of misconfiguration. Ping #single-machine-performance and we can help out.
Optimization Goals: ✅ No significant changes detected
|
perf | experiment | goal | Δ mean % | Δ mean % CI | trials | links |
---|---|---|---|---|---|---|
➖ | dsd_uds_500mb_3k_contexts | ingress throughput | +3.26 | [+3.14, +3.39] | 1 | |
➖ | dsd_uds_100mb_3k_contexts_distributions_only | memory utilization | +0.86 | [+0.73, +0.99] | 1 | |
➖ | dsd_uds_50mb_10k_contexts_no_inlining | ingress throughput | +0.02 | [-0.05, +0.09] | 1 | |
➖ | dsd_uds_50mb_10k_contexts_no_inlining_no_allocs | ingress throughput | +0.01 | [-0.05, +0.07] | 1 | |
➖ | dsd_uds_1mb_3k_contexts_dualship | ingress throughput | +0.00 | [-0.00, +0.01] | 1 | |
➖ | dsd_uds_40mb_12k_contexts_40_senders | ingress throughput | +0.00 | [-0.02, +0.03] | 1 | |
➖ | dsd_uds_100mb_3k_contexts | ingress throughput | +0.00 | [-0.05, +0.05] | 1 | |
➖ | dsd_uds_512kb_3k_contexts | ingress throughput | +0.00 | [-0.01, +0.01] | 1 | |
➖ | dsd_uds_1mb_50k_contexts | ingress throughput | -0.01 | [-0.02, +0.01] | 1 | |
➖ | dsd_uds_1mb_3k_contexts | ingress throughput | -0.01 | [-0.03, +0.00] | 1 | |
➖ | dsd_uds_10mb_3k_contexts | ingress throughput | -0.02 | [-0.04, +0.01] | 1 | |
➖ | quality_gates_idle_rss | memory utilization | -0.12 | [-0.15, -0.09] | 1 | |
➖ | dsd_uds_1mb_50k_contexts_memlimit | ingress throughput | -3.50 | [-4.00, -3.01] | 1 |
Bounds Checks: ✅ Passed
perf | experiment | bounds_check_name | replicates_passed | links |
---|---|---|---|---|
✅ | quality_gates_idle_rss | memory_usage | 10/10 |
Explanation
Confidence level: 90.00%
Effect size tolerance: |Δ mean %| ≥ 5.00%
Performance changes are noted in the perf column of each table:
- ✅ = significantly better comparison variant performance
- ❌ = significantly worse comparison variant performance
- ➖ = no significant change in performance
A regression test is an A/B test of target performance in a repeatable rig, where "performance" is measured as "comparison variant minus baseline variant" for an optimization goal (e.g., ingress throughput). Due to intrinsic variability in measuring that goal, we can only estimate its mean value for each experiment; we report uncertainty in that value as a 90.00% confidence interval denoted "Δ mean % CI".
For each experiment, we decide whether a change in performance is a "regression" -- a change worth investigating further -- if all of the following criteria are true:
-
Its estimated |Δ mean %| ≥ 5.00%, indicating the change is big enough to merit a closer look.
-
Its 90.00% confidence interval "Δ mean % CI" does not contain zero, indicating that if our statistical model is accurate, there is at least a 90.00% chance there is a difference in performance between baseline and comparison variants.
-
Its configuration does not mark it "erratic".
Regression Detector LinksExperiment Result Links
|
b1cda7c
to
d59b379
Compare
c695664
to
0a73476
Compare
d59b379
to
36f5486
Compare
5287ff7
to
0d1856f
Compare
…flushed during aggregation
0d1856f
to
0549c44
Compare
Context
When metrics are merged in the aggregate transform, we call
MetricValues::merge
, which is meant to uniformly handle the merge of different points for all metric types. This method handles both the merging of points based on their timestamp, as well as the specific merge behavior for the point values themselves.An issue was pointed out with how ADP was handling gauges, and after some debugging, it became apparent that when merging gauges, we were actually ignoring the timestamp but, which meant that if you had an existing point for a gauge, say with timestamp X, and you merged in another point with a timestamp Y, the first point would be entirely dropped.
This manifested itself as a fun bug where, due to the bucket width and flush interval defaults, a gauge being reported every 10 seconds was only ever emitted every 30 seconds.
Solution
While gauges nominally have "last write wins" behavior, that logic only applies for a given timestamp. This PR fixes the logic of merging gauges such that we don't drop the previous points, and only apply the LWW behavior when merging two points with an identical timestamp.
Further, we've added a number of unit tests to ensure the merging behavior is correct for each metric type. We've additionally added a number of
From
andDisplay
impls on the related types... some of which we only needed for initial debugging (but might be valuable in the future) and some of which are used by the unit tests.