Lower the default timeline window event budget to 400 - #5
Merged
Conversation
The 1500-event cap assumed 0.06 ms/event and almost never bound. Measured p50 is 0.479 ms/event; 400 puts cold builds near 190 ms on small hosts and makes the cap apply to more than two threads. Override with BB_FF_TIMELINE_WINDOW_EVENT_BUDGET. Related: get-bb#1749
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
1 participant
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.
Human comments
What was wrong
timelineWindowEventBudgetdefaulted to 1500, calibrated at ~0.06 ms/event so a cold build would stay near 100 ms. Measured p50 is 0.479 ms/event, so that same build is ~720 ms and blocks the serving loop. On a typical install the cap only bound for 2 of 76 threads; everyone else decoded the full event set on everymaxSeqchange.Related: get-bb/bb#1749.
What changed
timelineWindowEventBudgetis 400.BB_FF_TIMELINE_WINDOW_EVENT_BUDGETif you want the old window.docs/configuration.mdand the bb-guide customization template match.No protocol change. Pagination still walks full history; head-state banners are not scanned from the window.
Why this way
get-bb#1749 lists three options: calibrate at startup, budget on decoded bytes, or lower the constant. Calibrating and byte-budgeting are new machinery. 400 is the value the issue already measured as a workaround: cold builds ~190 ms on a 4-core host, and the cap binds for 19 threads instead of 2.
Raising the env var restores the previous window. We did not add a startup benchmark or change the cache key (
maxSeqstill invalidates). Those are later cuts.Benefit to bb
Every server, every thread that rebuilds a timeline window. Shorter stalls on the serving loop mean streams and other clients keep moving. Operators who need the old 1500-event window set the env var.
Harvest
Independent. Not yet opened on get-bb. Copy this body; Fixes get-bb#1749 if we want that linkage. Issue already proposed 400 as the workaround.
Decision record: docs/perf-control-plane.md (PR #9).
How you verified
packages/config/test/config.test.tsexpects the new default and still honors an explicit env override. 53 passed.Related: get-bb#1749