ci(peer-http): calibrate shared-runner routing latency gates - #41
Merged
Merged
Conversation
forhappy
marked this pull request as ready for review
October 2, 2026 02:13
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow up the merged #39 with the explicitly requested CI latency threshold adjustment. This PR changes only routing qualification and its documentation; production Rust is unchanged.
comparison.json, all raw samples, and record the blocking limits in both manifest and comparison.Calibration evidence and limits
The original-profile identical-binary control reported apparent 31.1% p95 /83.9% p99 increases with identical frozen source and executable hashes. The selected ceilings allow headroom over this observed shared-runner variation. Passing this coarse gate does not prove latency equivalence within 10% or a production SLO.
Historical results retain their original policy and failures. In particular, #39's old comparison failed forwarded commands at concurrency16 with p95/p99 ratios 1.140/1.244 leased and 1.213/1.465 object-only; throughput 0.950/0.987 passed. Those latency exceedances remain visible as alerts when replayed prospectively under this new policy. The raw audit confirms 484,384 latencies, 65,536 publication records, 98,304 exactly recovered commands.
Repeated identical-binary controls with CPU separation and independent providers also exceeded the old limits. They did not establish a provider/CPU fix or a code-versus-environment cause. No diagnostic instrumentation or experimental provider configuration is included here.
Verification
fbfd84f9c4dfcb6de497072efd9aafa5a6f409cc(merged perf(runtime): reduce forwarding admission and compaction publication latency #39). Candidate:a7db14750b24568a68efca98b5a743c87a8cc498.a45fe7135169785ecef3cc28edb1e18754adc323; baseline:fbfd84f9c4dfcb6de497072efd9aafa5a6f409cc. Plans and full audit reports are retained outside the repository.Plans and raw evidence remain outside the repository. PR #39 is left unchanged.