chore(#124): STG レイテンシー計測スクリプトを追加 - #139
Conversation
Issue #124 のボトルネック特定のため、計装ログを取得 / 突き合わせる 2 種のスクリプトを追加する。 - scripts/measure_staging.py: httpx + asyncio で url_id から trip_id / page_id / block_id を引いて Cookie を確立し、副作用の無い GET 6 エンドポイントをウォームアップ後に N 回ずつ直列に叩く。クライアント側 total_ms を p50 / p95 / avg / min / max で集計し、サンプル全件を JSONL で書き出して Cloud Logging と突き合わせ可能にする。 - scripts/fetch_latency_logs.sh: gcloud logging read で staging / production の Cloud Run jsonPayload.type="request" ログを期間指定で取得し、JSONL で stdout に出す。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a set of utility scripts designed to benchmark and analyze API latency in the staging environment. These tools facilitate bottleneck identification and performance validation for upcoming query and database optimization tasks by providing both client-side measurement and server-side log aggregation. Highlights
New Features🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
|
Visit the preview URL for this PR (updated for commit 585c833): https://tabi-share-8ef6b--pr139-perf-issue-124-stagi-jpch50ex.web.app (expires Sat, 30 May 2026 14:46:29 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: 9f2a87ede127df7673322845e34cf22c1372d720 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces two new scripts for performance monitoring: a shell script to fetch latency logs from Google Cloud Logging and a Python script to measure endpoint latency on the staging environment. The review feedback suggests improving code quality by replacing a lambda assignment with a formal function definition and adding input validation for the iteration count to prevent potential runtime errors during statistical analysis.
| async def _run(args: argparse.Namespace) -> None: | ||
| base_url = args.base_url.rstrip("/") | ||
| started_at = datetime.now(UTC).isoformat() | ||
| log = lambda msg: print(msg, file=sys.stderr) # noqa: E731 |
There was a problem hiding this comment.
PEP 8 では、lambda 式を直接変数に代入するのではなく、def を使用して関数を定義することが推奨されています。可読性と保守性の向上のため、ローカル関数として定義することをお勧めします。これにより noqa: E731 の指定も不要になります。
| log = lambda msg: print(msg, file=sys.stderr) # noqa: E731 | |
| def log(msg: str) -> None: | |
| print(msg, file=sys.stderr) |
| help="サンプル全件を書き出す JSONL ファイルパス (省略時は書き出さない)", | ||
| ) | ||
| args = parser.parse_args() | ||
| asyncio.run(_run(args)) |
There was a problem hiding this comment.
--iters に 0 以下の値が指定された場合、統計計算（statistics.fmean, min, max など）において StatisticsError や ValueError が発生し、スクリプトがクラッシュします。実行前にバリデーションを追加して、1 以上の値を強制するようにしてください。
| asyncio.run(_run(args)) | |
| if args.iters < 1: | |
| parser.error("--iters must be at least 1") | |
| asyncio.run(_run(args)) |
1 participant
概要
Issue #124 のボトルネック特定・改善検証に使う計測スクリプトを
scripts/配下に追加する。クエリ最適化 PR / DB 移行 PR の効果検証で再利用する想定で draft として置いておく。
詳細
scripts/measure_staging.py/health,/trips/url/{url_id},/trips/{trip_id},/trips/{trip_id}/pages,/pages/{page_id}/blocks,/blocks/{block_id}) を直列に N 回叩くtotal_msを p50 / p95 / avg / min / max で集計し、サンプル全件を JSONL で書き出して Cloud Logging との突き合わせを可能にするscripts/fetch_latency_logs.shgcloud logging readで Cloud Run のjsonPayload.type="request"ログを期間指定で取得して JSONL に整形動作確認
2026-05-23 に STG で実測実施。同じスクリプトで us-east-1 (現状) と Singapore (検証用) の両方を計測し、Cloud Logging の計装ログと突き合わせて 理論通りの RTT 半減 を確認した。
route 別 p50/p95 比較（n=30、ウォームアップ 5）
/trips/url/{url_id}/trips/{trip_id}/trips/{trip_id}/pages/pages/{page_id}/blocks/blocks/{block_id}計装内訳の比較
db_max_ms(PK SELECT 1 本) p50: us-east1=325.7ms → sg=159.6ms（≒ RTT 半減）total_ms - db_total_ms) p50: us-east1=660ms → sg=325ms（同上）。pool_pre_pingのSELECT 1や接続確立、prepare phase など middleware で測れていない部分も RTT 律速だったことが判明/healthp50: us-east1=37ms → sg=23ms（≒アプリ純粋オーバーヘッド）使い方
確認項目