パフォーマンス プロファイラー

Tier: POWERFUL
Category: Engineering
Domain: Performance Engineering

---

概要

Node.js、Python、Go アプリケーション向けの体系的なパフォーマンス プロファイリング。CPU、メモリ、I/O のボトルネックを特定し、フレームグラフを生成し、バンドル サイズを分析し、データベース クエリを最適化し、メモリ リークを検出し、k6 と Artillery を使用してロード テストを実行します。常に最適化前後の測定を行います。

コア機能

• CPU プロファイリング — Node.js 用フレームグラフ、Python 用 py-spy、Go 用 pprof
• メモリ プロファイリング — ヒープ スナップショット、リーク検出、GC 負荷
• バンドル分析 — webpack-bundle-analyzer、Next.js バンドル アナライザー
• データベース最適化 — EXPLAIN ANALYZE、スロー クエリ ログ、N+1 検出
• ロード テスト — k6 スクリプト、Artillery シナリオ、ランプアップ パターン
• 最適化前後の測定 — ベースライン確立、プロファイリング、最適化、検証

---

使用時機

• アプリが遅く、ボトルネックが不明な場合
• P99 レイテンシーがリリース前に SLA を超えている場合
• メモリ使用量が時間とともに増加している場合（リーク疑い）
• 依存関係を追加後にバンドル サイズが増加した場合
• トラフィック スパイクに備える場合（ローンチ前のロード テスト）
• データベース クエリが 100ms 以上かかる場合

---

クイック スタート

# プロジェクトのパフォーマンス リスク指標を分析
python3 scripts/performance_profiler.py /path/to/project

# CI 統合用の JSON 出力
python3 scripts/performance_profiler.py /path/to/project --json

# カスタム大規模ファイル閾値
python3 scripts/performance_profiler.py /path/to/project --large-file-threshold-kb 256

---

黄金律：測定が先

# 最適化前にベースラインを確立
# 記録: P50、P95、P99 レイテンシー | RPS | エラー率 | メモリ使用量

# 間違い: 「このN+1クエリは遅いと思うので修正しよう」
# 正解: プロファイル → ボトルネック確認 → 修正 → 再測定 → 改善を検証

---

Node.js プロファイリング

→ 詳細は references/profiling-recipes.md を参照してください

最適化前後の測定テンプレート

## パフォーマンス最適化: [修正内容]

**Date:** 2026-03-01  
**Engineer:** @username  
**Ticket:** PROJ-123  

### 問題
[1〜2文: 何が遅かったのか、どのように観察されたか]

### 根本原因
[プロファイラーが明らかにしたこと]

### ベースライン（最適化前）
| メトリクス | 値 |
|--------|-------|
| P50 レイテンシー | 480ms |
| P95 レイテンシー | 1,240ms |
| P99 レイテンシー | 3,100ms |
| RPS @ 50 VUs | 42 |
| エラー率 | 0.8% |
| DB クエリ/リクエスト | 23 (N+1) |

プロファイラー証拠: [フレームグラフまたはスクリーンショットへのリンク]

### 適用した修正
[変更内容 — コード差分または説明]

### 最適化後
| メトリクス | 最適化前 | 最適化後 | 変化 |
|--------|--------|-------|-------|
| P50 レイテンシー | 480ms | 48ms | -90% |
| P95 レイテンシー | 1,240ms | 120ms | -90% |
| P99 レイテンシー | 3,100ms | 280ms | -91% |
| RPS @ 50 VUs | 42 | 380 | +804% |
| エラー率 | 0.8% | 0% | -100% |
| DB クエリ/リクエスト | 23 | 1 | -96% |

### 検証
ロード テスト実行: [k6 出力へのリンク]

---

最適化チェックリスト

クイック ウィン（まずはこれらを確認）

データベース
□ WHERE/ORDER BY カラムのインデックス不足
□ N+1 クエリ（リクエストあたりのクエリ数を確認）
□ 必要な 2〜3 カラムのみなのに全カラムを読み込み（SELECT *）
□ 無制限クエリに LIMIT なし
□ コネクション プール不足（リクエストごとに新規接続を作成）

Node.js
□ ホットパス内の同期 I/O（fs.readFileSync）
□ ホット ループ内での大規模オブジェクトの JSON.parse/stringify
□ 高コスト計算のキャッシング欠落
□ レスポンスの圧縮（gzip/brotli）なし
□ リクエスト ハンドラー内での依存関係読み込み（モジュール レベルに移動）

バンドル
□ Moment.js → dayjs/date-fns
□ Lodash（フル）→ lodash/function インポート
□ 静的なコンポーネント インポート → 動的インポート
□ 画像が最適化されていない / next/image を使用していない
□ ルートでのコード分割なし

API
□ リスト エンドポイントでのペジネーション なし
□ レスポンス キャッシング（Cache-Control ヘッダー）なし
□ 並列化できる連続 await（Promise.all）
□ ループでの関連データ取得（JOIN の代わり）

---

よくある落とし穴

• 測定なしで最適化 — 間違った場所を最適化します
• 開発環境でテスト — 本番環境並みのデータ量に対してプロファイリングします
• P99 を無視 — P50 は問題なくても P99 が致命的なことがあります
• 早すぎる最適化 — 正確性を優先し、その後にパフォーマンスを改善します
• 再測定しない — 常に修正が実際に改善したことを検証します
• 本番環境でロード テスト — 本番環境規模のデータを使用したステージング環境で実施します

---

ベスト プラクティス

1. 常にベースラインから始める — 何かに手を付ける前にメトリクスを記録します
2. 一度に 1 つの変更 — 変数を分離して因果関係を確認します
3. 現実的なデータでプロファイル — 開発環境では 10 行、本番環境では数百万行 — ボトルネックが異なります
4. パフォーマンス予算を設定 — CI 閾値で k6 を使用し p(95) < 200ms など設定します
5. 継続的に監視 — キー パスの Datadog/Prometheus メトリクスを追加します
6. キャッシュ無効化戦略 — 積極的にキャッシュし、正確に無効化します
7. 成果を記録 — PR 説明で最適化前後を記載し、チームのモチベーションを高めます