perf(sidecar): event-driven pump to remove residual sync-RPC timer latency
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 48/100
- issue の種類
- 機能追加
- 明瞭さ
- 明確に書かれている
- 活発さ
- 静か
- 技術スタック
- rust
- 領域
- backend, performance
調査の方向性
crates/sidecar/src/stdio.rs から始めて、run_async、pump_process_events、process_event_receiver、および実行イベントチャネルを追跡します。キューに入れられたプロセスイベントによって、呼び出しごとのタイマー遅延やアイドルティックなしに select ループがウェイクアップされることを確認しつつ、粗いフォールバックも利用可能なままにします。
索引モデルが 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
- フォーク
- 53
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
rivet-dev/dynamic-apps のほかの issue
-
Build cache ignores maxResponseBytes, potentially reusing an outdated response limit対応中かも @Utkarshpandey0001 が 34 日前に担当しました。 オープン
難易度 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 が 39 日前に担当しました。 オープン
難易度 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 1週間以上 初心者へのやさしさ 35/100
rivet-dev/dynamic-apps#271 ·
rivet-dev/dynamic-apps の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
lyswhut/lx-music-desktop#3026 ·
-
area: ci type: test
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
schlessera/brain-kit#2769 ·
メンテナーはふだん 1 日以内に返信
-
Read a vector index's quantization back on Neo4j 2026.10, which reports vector.quantization.typeオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
liberation-data/drivine#231 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
alveusgg/alveusgg#2502 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信