s3wal: real-S3 e2e push p50 ~1.07 s (~2.8x the PG+S3 baseline on the same bucket region) — census and trim per-push S3 round trips

オープン
#182 コメント 3 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@ThomasK33 がすでに取り組んでいます。

2026年9月11日 から。

評価

この issue はまだ評価されていません。

説明

enhancement

From the 2026-08-27 real-S3 session (eu-central-1, ~7 ms HTTP RTT to the S3 endpoint): sequential empty-commit git push against a live serve node measured

  • s3wal (bucket = ref+meta authority + blobs): p50 1070 ms (n=20, p90 1171 ms)
  • PG+S3 (containerized Postgres + same-region S3 blobs): p50 386 ms (n=20)
  • loopback-SeaweedFS s3wal e2e (Phase 4 bench): p50 138 ms

The §3 simulated-push cell (manifest GET + 8 MiB pack PUT + 2 CAS advances) costs only ~204 ms p50 on the same bucket, so the e2e path is paying roughly 25–30 additional sequential S3 round trips' worth of latency per push somewhere between receive-pack, the update hook, hydrate, LFS/quota/meta accounting, and generation bumps. Known suspect: hook processes reconstruct stores from env URLs per invocation (fresh S3 client, config load, TLS) rather than reusing the serve process's connections.

Not a Gate 1a-B kill criterion (that gate measures the simulated-push cell, which passes with wide margin), but ~1.1 s per uncontended push is the number a real adopter feels. Worth: (1) a per-push S3 round-trip census (count + purpose), (2) trimming the obvious redundancies, (3) re-measuring.


Generated with mux • Model: anthropic:claude-fable-5 • Thinking: xhigh

主要言語
Go
スター
0
フォーク
0
平均マージ
6時間 16分
マージ済み PR(30日)
243

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

coder/openstorage のほかの issue

coder/openstorage の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。