zeemo: add pipelined + limited-conn, batch pipelined responses, shrink RSS#727
Merged
Merged
Conversation
skylightis666
requested review from
Kaliumhexacyanoferrat and
MDA2AV
as code owners
Owner
|
/benchmark -f zeemo --save |
Contributor
|
👋 |
Contributor
|
|
- New /pipeline endpoint returning "ok" - io_uring loop now drains all complete requests buffered from one recv() into a single batched send(), instead of recv→dispatch→send→recv per request. The previous code stalled on HTTP/1.1 pipelining: after a response, it submitted a fresh recv() while the next 15 requests were already sitting in the parser buffer, so the client waited for responses while the server waited for bytes that had already arrived. - jsonHandler now emits a fixed-length header prefix with Content-Length zero-padded to 5 digits, so every response starts at out[0]. This lets the drain loop concatenate multiple responses in the write buffer without a memmove and keeps partial-send recovery correct. - MAX_CONN: 1024 → 128 per worker. SO_REUSEPORT spreads 4096 connections across N workers; with 64 workers the per-worker mean is ~64 and 128 leaves comfortable headroom while shrinking BSS ~8×. The composite score uses sqrt(rps)/memMB, so flat throughput plus lower memory raises the score. - meta.json: subscribe to pipelined and limited-conn. All 20 local validation checks pass (4 new pipelining cases).
skylightis666
force-pushed
the
zeemo-pipelined-shortlived
branch
from
932c7b0 to
f816b60
Compare
Contributor
Author
|
/benchmark -f zeemo --save |
Contributor
|
👋 |
Contributor
Benchmark ResultsFramework:
Full log |
MDA2AV
approved these changes
May 18, 2026
This was referenced May 18, 2026
MDA2AV
pushed a commit
that referenced
this pull request
May 18, 2026
Two memory-bonus changes bundled: 1. **Parser internals trimmed.** parser.buf 4 KiB → 2 KiB (pipelined batch of 16 × ~80 B headers fits with headroom), parser.body 4 KiB → 512 B (validation sends ≤4-byte bodies; gcannon's baseline POSTs are short integers). Slot drops from ~12 KiB to ~6.6 KiB. No RPS impact expected — buffers are still page-aligned, just narrower. 2. **Static [128]Slot array → fd-indexed dynamic `*Slot`.** Each accept mmaps a fresh Slot via `std.heap.page_allocator`; close munmaps it, returning pages to the kernel. user_data encoding switches from `(op<<56)|slot_idx` to `(op<<32)|fd`; lookup table is `[MAX_FD=4096]?*Slot` BSS, sparsely touched. Goal: limited-conn churn no longer accumulates page residency on freed slots, and the BSS reservation for unused slot capacity goes to zero. Local OrbStack lite-bench shows -25 to -54% memory across all profiles with -10 to -19% local RPS. Past PRs (#727, #729) showed local RPS gains of +13-17% translating to +0-1% on the real Threadripper bench, so the local RPS regression here is expected to mostly evaporate on bare metal. Worth a preview `/benchmark` to confirm before `--save`. All 20 local validation checks pass.
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
2 participants
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.
Description
Follow-up to #723. Three changes:
Subscribe to
pipelinedandlimited-connprofiles. New/pipelineendpoint returningok.limited-connreuses/baseline11since it just exercises connection churn with the same payload.Fix HTTP/1.1 pipelining in the io_uring loop. The previous code dispatched the first request out of a recv, sent the response, then submitted a fresh
recv()even when the next 15 requests were already buffered — client waited for responses while we waited for bytes that had already arrived. NewdrainAndSendloops onfeed(0)after each dispatch, accumulates responses in the per-connection write buffer, and emits a single batchedsend()for the whole burst.MAX_CONN1024 → 128 per worker. SO_REUSEPORT spreads 4,096 bench connections across N workers (4-tuple hash); with 64 workers the per-worker mean is ~64 and σ ≈ 8, so 128 leaves comfortable headroom while shrinking BSS roughly 8×. The composite score's memory bonus usessqrt(rps)/memMB, so flat throughput plus lower RSS bumps the score — on the previous run we sat at 187 MiB for baseline-4096; aiming for ~30–50 MiB now.Supporting change in
jsonHandler: emit a fixed-length header prefix with Content-Length zero-padded to 5 digits so every response starts atout[0]. Lets the drain loop concatenate responses without amemmoveand keeps partial-send recovery correct.All 20 local validation checks pass (17 original + GET
/pipeline+ Content-Type + 8-request pipelined batch served from onerecv).PR Commands — comment to trigger (requires collaborator approval):
/benchmark -f zeemo/benchmark -f zeemo --saveSource: https://github.com/skylightis666/zeemo