Allow checks to cache their senders to reduce blocking operations #25858
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #25858 +/- ##
===========================================
+ Coverage 45.03% 53.92% +8.89%
===========================================
Files 2314 580 -1734
Lines 266564 51082 -215482
===========================================
- Hits 120038 27547 -92491
+ Misses 136977 22054 -114923
+ Partials 9549 1481 -8068
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Test changes on VMUse this command from test-infra-definitions to manually test this PR changes on a VM: inv create-vm --pipeline-id=34935651 --os-family=ubuntu |
Regression DetectorRegression Detector ResultsRun ID: d35bebed-4f39-473a-a22d-9e5646dfd8d5 Performance changes are noted in the perf column of each table:
No significant changes in experiment optimization goalsConfidence level: 90.00% There were no significant changes in experiment optimization goals at this confidence level and effect size tolerance.
|
| perf | experiment | goal | Δ mean % | Δ mean % CI |
|---|---|---|---|---|
| ➖ | basic_py_check | % cpu utilization | +1.14 | [-1.39, +3.68] |
| ➖ | file_tree | memory utilization | +0.41 | [+0.32, +0.50] |
| ➖ | idle | memory utilization | +0.40 | [+0.37, +0.44] |
| ➖ | tcp_dd_logs_filter_exclude | ingress throughput | +0.01 | [-0.01, +0.03] |
| ➖ | trace_agent_msgpack | ingress throughput | +0.00 | [-0.00, +0.00] |
| ➖ | trace_agent_json | ingress throughput | +0.00 | [-0.01, +0.01] |
| ➖ | uds_dogstatsd_to_api | ingress throughput | -0.00 | [-0.20, +0.20] |
| ➖ | otel_to_otel_logs | ingress throughput | -0.02 | [-0.37, +0.33] |
| ➖ | pycheck_1000_100byte_tags | % cpu utilization | -1.53 | [-6.28, +3.22] |
| ➖ | uds_dogstatsd_to_api_cpu | % cpu utilization | -1.80 | [-4.64, +1.05] |
| ➖ | tcp_syslog_to_blackhole | ingress throughput | -9.59 | [-29.56, +10.38] |
Explanation
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".
gh123man
added
the
qa/done
gh123man
changed the title
|
Sadly this didn't work as expected (doesn't cover python checks) so have to build out a different solution. |
What does this PR do?
Allow checks to cache their senders.
GetSenderandflushToSerializerboth hold the same lock. So if a flush takes a very long time, it could prevent checks from starting since today checks will always callGetSenderwhen they start. This PR allows checks to re-use their sender so they don't have acquire the senders more than once in the lifetime.Additional context
This PR is one part of a solution to a bigger problem: Some checks that send an extremely high volume of metrics can cause other checks to block due to very long flushes. The flush mechanism several parts, but I am most interested in the aggregator check sampler flush. As a whole, these operations are blocking and prevent checks from starting until a flush finishes but with this change, we can scope the blocking behavior down to just the check sampler instead of "everything".
This PR removes the need for checks to block on the demultiplexer. On top of this, all of the interactions between the sender and check sampler are buffered - so we can tune them with various existing agent settings reducing the impact of blocking on the check sampler's channel operations
Motivation
Additional Notes
Possible Drawbacks / Trade-offs
Describe how to test/QA your changes
This has already been deployed to a large cluster so testing should be done.
Manual steps: ensure checks still work correctly (lifecycle, and metrics)