Maincloud: subscription deliveries freeze 7–63 s under large fan-out (repro, 2.10.1)
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 28/100
- issue の種類
- バグ
- 明瞭さ
- 説明が足りない
- 活発さ
- 活発
- 技術スタック
- typescript
調査の方向性
Start with the Maincloud database coinsteam-staging-stall-probe and reproduce the 230-subscriber set_beat workload described in the issue. Compare delivery gaps across the reported client vantages and review the available probe scripts and raw timings. Done means identifying whether Maincloud WebSocket ingress or host egress causes the stalls and documenting a confirmed mitigation or fan-out limit.
索引モデルが issue の本文から書いたものです。
説明
Summary
On Maincloud, when one transaction's update fans out to 50–230 WebSocket subscribers at once (~10–90 MB in total), some connections stop receiving bytes for ~7.5 / 15 / 31 / 63 s after the reducer call has returned, then receive the rest in one burst. The gaps match TCP retransmission backoff, which suggests repeated packet loss somewhere on the Maincloud side (front end or host egress).
Why we think it is platform-side
- It happened at the same moments, with the same worst cases, to clients on three independent vantages: two Linux hosts on one ISP, and Cloudflare Durable Objects using raw WebSockets (no SDK). Example: 45.1 / 45.0 / 45.0 s on the same transition.
- A frozen connection receives 12–160 KB of the update, then zero bytes for 7.5, 15 or 30 s, then the remainder. The client event loop lagged ≤ 21 ms and the client kernel dropped nothing; bytes stop arriving before the client reads them.
- Same behaviour with confirmed reads on and off.
- Light traffic is clean: 28,440 small deliveries peaked at 438 ms. Once, 2 KB updates froze ~28 s about 2 minutes after a heavy run, so the effect seems to linger.
Minimal repro (SpacetimeDB 2.10.1, TypeScript module)
- One public table
beat { id: u32 (pk), n: u64, pad: string, at: timestamp }. - Reducer
set_beat(n: u64, padLen: u32)overwrites row 1 with apadofpadLenbytes. - 230 subscribers to
SELECT * FROM beat. - Call
set_beat(n, 200000)every 8 s. - Result: last-subscriber lag up to ~61 s, and ~25 % of deliveries arrived more than 2.5 s late.
The repro database is coinsteam-staging-stall-probe on Maincloud; we can keep it up for you. Happy to share the probe scripts and raw timings.
Questions
- Is there burst shaping or policing on Maincloud's WebSocket front end or host egress?
- Is this a known issue, and is there a recommended limit on per-transaction fan-out bytes?
Why it matters to us: we rely on subscription updates to remove revoked data from users' screens within a bounded time. A frozen connection also delays those deletions.
- 主要言語
- Rust
- スター
- 25.2k
- フォーク
- 1.1k
- 平均マージ
- 3日 21時間
- マージ済み PR（30日）
- 44
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートあり
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
clockworklabs/SpacetimeDB のほかの issue
-
CI flake: Lintsオープン
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
clockworklabs/SpacetimeDB#5985 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
clockworklabs/SpacetimeDB#5943 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
clockworklabs/SpacetimeDB#5851 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
clockworklabs/SpacetimeDB#5693 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
clockworklabs/SpacetimeDB#5587 ·
メンテナーはふだん 1 日以内に返信
clockworklabs/SpacetimeDB の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
trezor/trezor-firmware#7997 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
smol-machines/smolvm#1489 · コメント 1 件 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信