You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
test(observability-map): size the real-tree timeouts for shard contention
The 30s and 60s per-test timeouts on the two real-tree tests were chosen on an
idle machine, and the suite also runs inside unit-tests-internal.yml, which
executes turbo run test --filter "@internal/*" as twelve concurrent shard
processes on one runner. The 30s one does flake under that.
Measured on an 8-core box. This file alone at load average 0.9: 6.3-6.4s for the
scan, 10.8-11.2s for the sweep, both well above the 1.6-2.6s the old comment
claimed. Two batches of twelve concurrent copies on those same 8 cores: 24.2-34.0s
for the scan and 27.6-39.7s for the sweep, with one of the first twelve dying on
"Test timed out in 30000ms". Twelve processes over 8 cores is 1.5 per core where
the 32-vCPU runner is 0.375, so the reproduction is harsher than CI, which is why
it is the thing to size against.
Both now use one 120s constant, which is 3x the worst contended run measured.
60s was the other candidate and is not enough: the sweep already reached 39.7s.
Neither test asserts anything about elapsed time, so the number is a hang
detector rather than a performance budget, and the docstring says so.
Reported by Devin on #4455.
0 commit comments