From e81a7887762fff8c4e9b31d38bd77a9c4546a2a4 Mon Sep 17 00:00:00 2001 From: Kerry Lu Date: Fri, 11 Sep 2026 13:43:53 -0700 Subject: [PATCH] test(e2e): hold chaos CPU per request to 2x Three local runs measured 1.33x-1.36x, so 2x is the tightest bound the data supports and still catches a regression far smaller than 4x would. Noted in the comment that this is the ceiling to loosen first if a weekly run trips it, since core count shifts how much of baseline CPU is fixed per-request work. Co-Authored-By: Claude Code --- tests/e2e/load/test_redis_chaos_e2e.py | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tests/e2e/load/test_redis_chaos_e2e.py b/tests/e2e/load/test_redis_chaos_e2e.py index c1da41aeb16..c800ccb0e51 100644 --- a/tests/e2e/load/test_redis_chaos_e2e.py +++ b/tests/e2e/load/test_redis_chaos_e2e.py @@ -74,9 +74,11 @@ REDIS_PAUSE_MS: Final = int(CHAOS_SECONDS * 1000) # are machine-shaped: RSS scales with worker count and CPU with core count, so a number # calibrated on one runner means nothing on another. RSS moved 0.91x-1.40x across three otherwise # identical local runs, so it stays loose; CPU per request held steady at 1.33x-1.36x across the -# same runs, so it can sit closer to what is actually measured. +# same runs, so it sits close to what is actually measured. That makes CPU the likeliest of these +# to flake first on a runner whose core count shifts how much of baseline CPU is fixed per-request +# work: loosen it rather than widening the others if a weekly run trips it without a real cause. CHAOS_RSS_RATIO_CEILING: Final = 2.0 -CHAOS_CPU_PER_REQUEST_RATIO_CEILING: Final = 4.0 +CHAOS_CPU_PER_REQUEST_RATIO_CEILING: Final = 2.0 # Latency and log volume get flat ceilings instead, because a ratio cannot bound either one. Once # the breaker opens, a request skips Redis rather than waiting on its socket timeout, so the chaos