Repository navigation
perf(acpmux): use fuller pages for large session censuses - #30482
Conversation
GitHub Actions
Error
GitHub Actions
Inactive
|
cmux status (one comment, edited in place; each line is updated by the job that owns it) Review App of this head (app.zip, kept 1 day)
Shipped in:
|
teamleaderleo
left a comment
teamleaderleo
left a comment
There was a problem hiding this comment.
Review (claude-opus-5-5 medium): SHIP at 24394b3
Review (subagent claude-opus-5-5 medium): SHIP at 24394b3
Carried from an independent Opus 5.5 medium subagent review supplied by the coordinating session. No correctness blockers: adaptive enumeration matches the fixed reader on 8,000 rows; byte bounds, halving fallback, explicit cursor/limit behavior and usage projection remain correct.
Follow-ups: target roughly 90% of NEAR_CAP_BYTES to avoid routine near-cap warnings and reduce expensive oversized-page retries on heterogeneous peer rows. Synthetic test timings do not include transport and must not stand in for end-to-end latency. The PR labels those timings accordingly.
|
Review follow-up tracked in #30520: leave additional headroom below the near-cap warning threshold and extend mixed-size census coverage. The measured harness wall time excludes transport; updated-build end-to-end measurements remain separate. |
…1 MiB limit (#30482's count was for 15 MiB)
…ures sized from the limit (#30808) * Re-land #29670: remove the 15 MiB message cap (31 MiB) Re-applies b9d493d, taken back in #30184 because send_attach_family's too-large fixture still sent 15.7 MiB. ls_pages_tests keeps #30482's page wording with #29670's 31 MiB fixture. The next commit sizes the attach fixture from the limit. * send_attach_family's too-large send is sized from the message limit #29670 raised rpc::MAX_MESSAGE_BYTES from 15 to 31 MiB; this fixture still sent 5 MiB of text and an 8 MiB file (about 15.7 MiB), which then fit, so attach.tooLarge never came (the reason #30184 took #29670 back). It is now half the limit as text and half as a file, about 1.2 times the limit. * re-land #29670: the 8,000-row census reads in 2 fuller pages at the 31 MiB limit (#30482's count was for 15 MiB)
A full
acpmux lson a host with about 8,000 mirrored sessions took roughly 70 seconds, whilels --livetook 2 seconds. The CLI always requested 1,000 rows per page, requiring eight separately paced list requests; active sessions can invalidate the shared snapshot between requests.--json --fields sessionId,name,statusalso requested usage refresh even though it displayed none.Full census reads now measure the first successful reply and size subsequent pages to use the existing wire-size headroom. Explicit single-page reads keep their requested count. The existing byte bounds and halve-on-too-large fallback remain authoritative; after a refusal, the reader keeps the smaller page size rather than growing again. Field projections request usage refresh only when they include
usageStats.Leo's request: "optimize against that for acpmux/cmux-next and whatever agents try to do".
Performance
an_eight_thousand_row_peer_census_uses_fuller_pages, same fake daemon with fixed versus adaptive request sizes| harness wall time, same 8,000 rows | 157.491 ms | 88.787 ms | -43.6% | same fleet harness |
The harness also prints wall time for both arms and verifies identical rows and message sizes below the cap. This measures CLI pagination, not the end-to-end time on the reporting Mac. The companion #30470 fixes stale list-pacing debt independently.
Validation and risk
Validation route:
fast_checks_fleet.run_on_fleetthrough the fleet controller, Linux pool job54e5fdd3937a2ad537ca2682at the pushed head. This replaces the fast-checks Actions dispatch that queued without a runner; passed: 18 tests, 0 failures (the 8,000-row reply peaked at 11,814,426 bytes).Focused fleet tests:
ls_pages,projected_listings_only_refresh_usage_when_they_show_it. Existing tests cover old daemons, oversized replies, duplicate cursors, explicit pages, limits and filters. Added coverage checks an 8,000-row mirror and much larger rows after the first page.No timer, observer or retained cache is added. The byte estimate runs once per full listing, using a counting writer that allocates no serialized copy. Risk: heterogeneous rows can make the estimate too large, handled by the existing smaller-page retry. No sessions are omitted or expired.
Prior art: #28373 introduced safe paging against old daemons; #28831 bounds every server list page by bytes. Both remain in effect.
Agent session: agent session