enhancement: add RetryCircuitBreaker middleware
#551
Conversation
Regression Detector (Saluki)Regression Detector ResultsRun ID: c38871cd-7e45-4dd0-899c-c7a9d55d55ce Baseline: 0552851 Optimization Goals: ✅ No significant changes detected
|
| perf | experiment | goal | Δ mean % | Δ mean % CI | trials | links |
|---|---|---|---|---|---|---|
| ➖ | dsd_uds_500mb_3k_contexts | ingress throughput | +0.40 | [+0.30, +0.50] | 1 | |
| ➖ | quality_gates_idle_rss | memory utilization | +0.12 | [+0.04, +0.20] | 1 | |
| ➖ | dsd_uds_100mb_3k_contexts_distributions_only | memory utilization | +0.04 | [-0.07, +0.14] | 1 | |
| ➖ | dsd_uds_100mb_250k_contexts | ingress throughput | +0.01 | [-0.03, +0.05] | 1 | |
| ➖ | dsd_uds_1mb_3k_contexts_dualship | ingress throughput | +0.01 | [-0.01, +0.02] | 1 | |
| ➖ | dsd_uds_50mb_10k_contexts_no_inlining | ingress throughput | +0.01 | [-0.09, +0.10] | 1 | |
| ➖ | dsd_uds_100mb_3k_contexts | ingress throughput | +0.00 | [-0.06, +0.06] | 1 | |
| ➖ | dsd_uds_512kb_3k_contexts | ingress throughput | +0.00 | [-0.01, +0.01] | 1 | |
| ➖ | dsd_uds_40mb_12k_contexts_40_senders | ingress throughput | +0.00 | [-0.03, +0.04] | 1 | |
| ➖ | dsd_uds_10mb_3k_contexts | ingress throughput | +0.00 | [-0.03, +0.03] | 1 | |
| ➖ | dsd_uds_1mb_50k_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_50mb_10k_contexts_no_inlining_no_allocs | ingress throughput | -0.01 | [-0.09, +0.07] | 1 | |
| ➖ | dsd_uds_1mb_50k_contexts_memlimit | ingress throughput | -0.11 | [-0.42, +0.20] | 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
|
tobz
force-pushed
the
tobz/circuit-breaker-tower-middleware
branch
from
e558885 to
6572b3c
Compare
Summary
This PR implements a new Tower middleware,
RetryCircuitBreaker. It is designed to help mimic the retry behavior used in the Datadog Agent which involves a blend of both traditional retry behavior (try again after a period of time) and circuit breaker behavior (all requests made while the circuit is open will fail).Currently, we use the generic retry middleware provided in the
towercrate, but this comes with a particular downside: requests have to proceed sequentially, and one request being stuck blocks all other requests behind it. The Datadog Agent will intentionally divert additional incoming requests to a "retry queue" when a worker is fully saturated, and when a given endpoint is currently being backed off due to a previous error(s). This is hard to accomplish as-is with the generic retry middleware because we can't differentiate between the request still executing on its first attempt or having gone into trying further attempts, which means once we make the service call, we're stuck waiting for it.RetryCircuitBreakeris a middleware implementation that allows using an existing retryPolicyfromtower-- so we can take advantage of what we've already got -- and uses it to determine if a response constitutes a success or failure. When a request fails, the middleware itself modulates its readiness -- if we're instructed to back off for N seconds, the service will then not report as ready for N seconds -- but the response is immediately returned, indicating to the caller that the call failed and the circuit is now open.What this allows us to do is await service readiness to match the behavior of not starting a request at all while we're in backoff, which in turn will allow us to choose to divert incoming requests to a retry queue until the service becomes ready. Additionally, the service can return the original request when the circuit breaker is open or when the request fails in a retryable way, which means the code using this middleware doesn't have to hold on to its own copy of the request to potentially requeue it later on if it fails.
Notes
I'm leaving any changes to actually use this middleware for follow-up PRs.
Change Type
How did you test this PR?
Unit tests only.
References
N/A