perf: move streaming command processing off async workers - #529
Merged
Mohamed Mansour (mohamedmansour) merged 1 commit intoSep 12, 2026
Merged
Conversation
Move owned start and resume state into the continuation and decode bounded NDJSON records on the existing blocking renderer. Preserve the original transport and pool sizing, error classifications, cancellation, and precommit behavior. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This was referenced Sep 11, 2026
Copilot started reviewing on behalf of
Mohamed Mansour (mohamedmansour)
September 12, 2026 00:31
View session
mcritzjam
approved these changes
Sep 12, 2026
Contributor
There was a problem hiding this comment.
🔵 Needs a closer look
The streaming execution-boundary changes warrant final human review.
Pull request overview
Moves streaming command parsing and state preparation to the blocking renderer while preserving backpressure, limits, ordering, and error classification.
Changes:
- Transfers raw records through the capacity-one channel.
- Adds focused streaming regressions.
- Updates ownership, performance, and architecture guidance.
File summaries
| File | Summary |
|---|---|
docs/guide/integrations/rust.md |
Updates owned-state streaming guidance. |
docs/guide/concepts/performance.md |
Adds performance guidance for streaming state. |
DESIGN.md |
Documents the updated streaming architecture. |
crates/webui-cli/src/commands/serve/streaming_api.rs |
Moves decoding and state preparation to the renderer and adds regressions. |
Review details
- Files reviewed: 4/4 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Mohamed Mansour (mohamedmansour)
deleted the
mohamedmansour/streaming-command-processing
branch
September 12, 2026 01:00
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
*No streaming chunk-size, pool-retention, pool-sizing, watcher, or dependency changes are included.
Recorded before/after evidence
These measurements already isolated exactly the combined CLI ownership/worker-processing change, with the original transport and pool sizing in both variants. The split retains identical production code; its test-helper pool capacity also matches the measured original
CHUNK_TARGET + 1024.The recorded A/B baseline was
f43db65067d48581ed7f99acc4b8d68f201c8bb9. This PR is based on newer main2dab6fc6; the measurements were not rerun against that newer base. The intervening main changes did not modify this CLI module or the streaming writer. Ownership and parsing-placement effects were not independently ablated.Method
Intel Core Ultra 9 285K; Linux x86_64 WSL2
6.6.114.1-microsoft-standard-WSL2; Rust/Cargo 1.98.0; release/thin-LTO. Three sequential before/after pairs pinned to CPUs 8 and 9. Each run/case used 40 warmups plus 180 latency responses: 540 measured responses per variant/case.The harness measures actual private
render()throughto_bytes(), with prebuilt NDJSON delivered as 16 KiB in-memory backend chunks. It is not TCP or whole-server throughput. Start/resume retain a largerowssubtree, and resume changes it. Components projection keeps output small to isolate processing.Every individual record stays below 2,000,000 bytes. All 487-byte bodies/checkpoints matched across cases, variants, warmups, and timed responses. Setup serialization, configuration, chunk clones, byte comparison, and CSV writing were outside the timing window.
Latency and CPU
All values are microseconds, median / P95, pooled across three runs. P50 uses the sample median; P95 uses sorted index
floor((n - 1) * 0.95). CPU uses Linux process/current-thread CPU clocks.At 1 MiB, median wall latency falls approximately 45.5% and event-thread CPU approximately 96.8%. Small-response scheduling variance remains visible; these figures do not promise an equivalent server-wide RPS increase.
Separate cooperative ticker measurement
A continuously yielding task on the current thread records the maximum inter-tick gap per response. This phase is separate because spinner CPU must not be used as throughput evidence. It used 40 warmups plus 90 measured responses per run: 270 responses per variant/case.
Values are microseconds, median / P95 of the per-response maximum gap.
Whole-process RSS high-water observations were before 54,372 / 54,136 / 55,336 KiB, after 50,736 / 61,040 / 82,960 KiB. They include setup, warmups, ticker activity, and allocator retention and establish neither a memory improvement nor regression. No allocation-count trace was collected.
Reproduction
cargo test --release -p microsoft-webui-cli --no-run WEBUI_BENCH_ITERATIONS=180 WEBUI_BENCH_OUTPUT=before-1 \ taskset -c 8,9 ./before-test measured_cli_render_pipeline --nocapture --test-threads=1 WEBUI_BENCH_ITERATIONS=180 WEBUI_BENCH_OUTPUT=after-1 \ taskset -c 8,9 ./after-test measured_cli_render_pipeline --nocapture --test-threads=1Repeat three sequential pairs, pooling raw CSV samples by case and phase. Use separate Cargo targets, or force the CLI rebuild in an isolated shared target: archived same-mtime sources can otherwise reuse the wrong executable.
Validation
The focused
cargo test -p microsoft-webui-cli streaming_apiselection and completecargo xtask checkpassed on this independent branch. The gate included docs, workspace/WASM builds, examples, and benchmark smoke. The full gate completed in 83.7 seconds.Regression coverage includes raw-byte ownership/backpressure, worker-side default preparation, initial error classification, and worker parse failure while the backend stalls. Public protocol version 2, the 2 MB record cap, and the 4 MB precommit cap are unchanged.