perf(sidecar): event-driven pump to remove residual sync-RPC timer latency
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 48/100
- Issue 类型
- 功能
- 描述清晰度
- 描述清楚
- 活跃度
- 冷清
- 技术栈
- rust
- 领域
- backend, performance
调研方向
从 crates/sidecar/src/stdio.rs 开始，跟踪 run_async、pump_process_events、process_event_receiver 和执行事件通道。验证排队的进程事件能够唤醒 select 循环，而不会产生每次调用的计时器延迟或空闲 tick，同时保留粗粒度 fallback 可用。
由索引模型根据 Issue 内容生成。
描述
Background
Guest sync fs/module RPCs are serviced by pump_process_events, which the stdio
select loop (crates/sidecar/src/stdio.rs) only runs on the EVENT_PUMP_INTERVAL
timer. PR #77 reduced that interval from 5 ms to 250 µs, which cut per-call
latency dramatically (stat 7.5s→1.3s, read 7.6s→1.2s over 1500 ops). But it is
still a polling timer: a blocked guest call waits up to one interval before the
host dequeues it, and the loop wakes on every tick even when nothing is pending.
Proposal
Make the pump event-driven: wake the stdio select loop the instant the
execution layer enqueues a process event (e.g. a JavascriptSyncRpcRequest),
instead of relying on the timer. Concretely, plumb a notify signal from the
execution event channel up into the run_async select loop (an extra select!
arm that awaits "a process event is ready"), and keep a coarse timer only as a
fallback. This removes the residual ~250 µs/call timer latency and the idle-tick
cost entirely.
Notes / constraints
- An adaptive fine/coarse interval was tried in PR #77 and was unstable
(oscillation/livelock under load) because it recreatedtokio::time::interval
mid-select. A true notify channel avoids that. pump_process_eventsalready returns whether it did work; the receiver
(process_event_receiver) is currently drained viatry_recvinside the pump,
so an event-driven design must coordinate a single consumer.
Expected impact
Removes the remaining timer latency on every guest sync fs/module RPC; biggest
remaining win for fs-heavy guests after PR #77.
- 主要语言
- TypeScript
- 星标
- 1k
- 派生
- 54
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
rivet-dev/dynamic-apps 的其他 Issue
-
Build cache ignores maxResponseBytes, potentially reusing an outdated response limit可能已有人在做 @Utkarshpandey0001 于 18 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 78/100
rivet-dev/dynamic-apps#297 ·
-
难度 3/5 1-2 天 新手友好度 58/100
rivet-dev/dynamic-apps#280 · 2 条评论 ·
-
Make agentOS runtime classifier content-based (match Linux exec semantics), not extension-based可能已有人在做 @mittal-parth 于 23 天前认领。 未关闭
难度 4/5 3-5 天 新手友好度 48/100
rivet-dev/dynamic-apps#275 ·
-
难度 4/5 3-5 天 新手友好度 55/100
rivet-dev/dynamic-apps#272 ·
-
Treat the WASM/WASI build target as cfg(unix) so filesystem tools need no per-tool mode-bit patches未关闭
难度 5/5 一周以上 新手友好度 35/100
rivet-dev/dynamic-apps#271 ·
查看 rivet-dev/dynamic-apps 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
rajbos/ai-engineering-fluency#2340 · 1 条评论 ·
维护者通常 1 天内回复
-
community documentation first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
难度 1/5 1 小时以内 新手友好度 70/100
lingdojo/kana-dojo#31864 · 1 条评论 · 5 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
zenstackhq/zenstack#2873 ·
维护者通常 1 天内回复
-
CLI: TUI shows onboarding when the provider's API key is only in the environment (e.g. OPENROUTER_API_KEY)可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭CLI
难度 2/5 1-3 小时 新手友好度 67/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
paperclipai/paperclip#15490 ·
维护者通常 1 天内回复