test(e2e): tighten chaos RSS and CPU ceilings to what runs actually measured

RSS moved 0.91x-1.40x across three identical local runs, so it stays loose at
2x rather than the arbitrary 1.5x carried over from the pre-padding-payload
calibration. CPU per request held steady at 1.33x-1.36x across the same runs,
so 4x replaces the looser 6x it inherited from stale numbers.

Co-Authored-By: Claude Code <noreply@anthropic.com>
This commit is contained in:
Kerry Lu 2026-09-11 13:43:18 -07:00
parent cc1d2c66c8
commit 1d71006567

View file

@ -72,12 +72,11 @@ REDIS_PAUSE_MS: Final = int(CHAOS_SECONDS * 1000)
# RSS and CPU are budgeted as a multiple of the same metric in the baseline phase, because both
# are machine-shaped: RSS scales with worker count and CPU with core count, so a number
# calibrated on one runner means nothing on another. Calibrated from local runs under CLIENT
# PAUSE ALL that came in around 1.03x RSS and 4.4x CPU per request, and deliberately loose: the
# regression these guard against grew memory by an order of magnitude, so catching it does not
# need a tight bound, and a tight one would flake on a shared CI runner.
CHAOS_RSS_RATIO_CEILING: Final = 1.5
CHAOS_CPU_PER_REQUEST_RATIO_CEILING: Final = 6.0
# 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.
CHAOS_RSS_RATIO_CEILING: Final = 2.0
CHAOS_CPU_PER_REQUEST_RATIO_CEILING: Final = 4.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