Reduce stage log Put allocation overhead in filestore persistence

オープン
  • 何か問題がありますか？
#7,026 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

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

2026年10月18日 から。

  • #7027 @rootp1 による — マージされずにクローズ

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
58/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
静か
技術スタック
go
領域
backend

調査の方向性

pkg/app/server/stagelogstore/filestore.go から始め、65-82 行付近の stageLogFileStore.Put と、そのパフォーマンス TODO を読みます。issue に記載された、増加する lf.Blocks を対象とする集中的なベンチマークを追加し、その後、既存の読み取り動作を確認しながらアロケーションと書き込みコストを比較します。測定可能な改善があり、行区切り形式と EOL マーカーが維持され、無関係な動作の変更がないことが完了の条件です。

索引モデルが issue の本文から書いたものです。

説明

What happened:

Summary

stageLogFileStore.Put rewrites the entire stage-log fragment on every save by JSON-encoding each LogBlock into a fresh in-memory buffer and then writing the full byte slice to the filestore. The code already carries a TODO for this hot path, and the current implementation scales allocations and latency with total block count on every write.

Affected Area

  • pkg/app/server/stagelogstore/filestore.go
  • stage log persistence in the control plane filestore path

What you expected to happen:

Large or frequently updated stage logs should be persisted with lower peak allocation overhead and an encoding path that does not materialize avoidable intermediate payloads for every block.

How to reproduce it:

  1. Open pkg/app/server/stagelogstore/filestore.go.
  2. Inspect stageLogFileStore.Put around the existing performance TODO.
  3. Note that each call loops over all lf.Blocks, marshals each block individually, appends it to a bytes.Buffer, and finally calls filestore.Put with the complete byte slice.
  4. Add a focused benchmark that grows lf.Blocks and repeatedly calls Put.
  5. Observe allocation count and write cost grow with total block count because the full fragment is rebuilt for every save.

Environment:

  • piped version: repository checkout on 2026-07-13
  • control-plane version: repository checkout on 2026-07-13
  • Others: validated by current code inspection; previous related issue #40 was closed as stale, not fixed

Technical Evidence

  • pkg/app/server/stagelogstore/filestore.go:65-82 rebuilds the payload in memory for every Put
  • The code includes TODO: Reduce the number of marshaling log blocks for improving performance
  • Upstream issue #40 tracked the same performance concern but was auto-closed as stale without an implementation change

Suspected Root Cause

The filestore path is implemented as full-object persistence, and Put currently uses per-block json.Marshal calls plus a whole-fragment buffer build before every write.

Proposed Direction

Start with a benchmark for realistic stage-log sizes, then refactor the write path to stream JSON encoding into the final buffer or otherwise reduce avoidable intermediate allocations while preserving the existing line-delimited on-disk format and EOL completion marker.

Acceptance Criteria

  • A benchmark captures baseline throughput and allocations for larger stage-log fragments
  • The write path measurably reduces allocations or latency compared with the current implementation
  • Existing read compatibility for stored stage logs is preserved
  • No unrelated stage-log behavior changes are introduced
主要言語
Go
スター
1.4k
フォーク
391
平均マージ
4日 1時間
マージ済み PR（30日）
58

環境構築

はじめの一歩

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

pipe-cd/pipecd のほかの issue

pipe-cd/pipecd の issue をすべて見る

似ている issue

Go の issue をもっと見る

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

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