perf-profile

/perf-profile

アプリケーションのパフォーマンスをプロファイリングします。コードの実行時間、DB 呼び出し時間、アプリケーション層とデータベース層の両方におけるボトルネックを特定します。

Step 1: 対象を特定する

ユーザーに尋ねる（またはコンテキストから推測する）：何をプロファイリングしますか？

• 特定のエンドポイント／ルート
• バックグラウンドジョブ／ワーカー
• 特定の関数またはモジュール
• アプリケーション全体（全般的な監査）

Step 2: DB 呼び出し時間のプロファイリング

PostgreSQL

# Enable timing in psql
psql "$DATABASE_URL" -c "\timing on"

# Check pg_stat_statements for query timing (if available)
psql "$DATABASE_URL" -c "
  SELECT
    LEFT(query, 80) AS query,
    calls,
    ROUND(mean_exec_time::numeric, 2) AS mean_ms,
    ROUND(total_exec_time::numeric, 2) AS total_ms,
    ROUND((total_exec_time / SUM(total_exec_time) OVER ()) * 100, 1) AS pct_total
  FROM pg_stat_statements
  ORDER BY mean_exec_time DESC
  LIMIT 20;
" 2>/dev/null || echo "pg_stat_statements not available — enable with: CREATE EXTENSION pg_stat_statements;"

MySQL / MariaDB

mysql -e "
  SELECT
    LEFT(DIGEST_TEXT, 80) AS query,
    COUNT_STAR AS calls,
    ROUND(AVG_TIMER_WAIT/1e9, 2) AS mean_ms,
    ROUND(SUM_TIMER_WAIT/1e9, 2) AS total_ms
  FROM performance_schema.events_statements_summary_by_digest
  ORDER BY AVG_TIMER_WAIT DESC
  LIMIT 20;
" 2>/dev/null || echo "MySQL performance_schema unavailable"

報告内容：平均実行時間の上位 20 件のクエリを、呼び出し回数と DB 時間全体に占める割合とともに表にまとめます。

Step 3: アプリケーションレベルのプロファイリング

実行環境を検出し、適切なプロファイラーを提案する：

# Detect language/framework
[ -f package.json ] && echo "RUNTIME=node"
[ -f Gemfile ] && echo "RUNTIME=ruby"
[ -f requirements.txt ] || [ -f pyproject.toml ] && echo "RUNTIME=python"
[ -f go.mod ] && echo "RUNTIME=go"
[ -f pom.xml ] || [ -f build.gradle ] && echo "RUNTIME=java"

Node.js：

• 組み込み機能：node --prof app.js + node --prof-process isolate-*.log
• Web アプリケーションの場合：--inspect を追加し、Chrome DevTools プロファイラーを使用します
• 提案：フレームグラフの作成には clinic.js（npx clinic doctor -- node app.js）を使用します

Ruby：

• 提案：Rails には stackprof または rack-mini-profiler を使用します
• 特定のメソッドの場合：Benchmark.measure { ... } で囲みます

Python：

• 組み込み機能：python -m cProfile -s cumulative script.py
• Web アプリケーションの場合：ライブプロファイリングには py-spy top --pid <pid> を使用します
• 提案：可視化には snakeviz を使用します

Go：

• 組み込み機能：go tool pprof http://localhost:6060/debug/pprof/profile
• エンドポイントを有効にするには import _ "net/http/pprof" を追加します

既存の時間計測用インストルメンテーションを検索する：

grep -rn "benchmark\|timing\|elapsed\|duration\|stopwatch\|time\.now\|Time\.now\|perf_hook\|performance\.now" \
  --include="*.rb" --include="*.py" --include="*.js" --include="*.ts" --include="*.go" \
  . 2>/dev/null | head -20

Step 4: コードレベルのボトルネックをスキャンする

コードベース内に、よくあるパフォーマンス上のアンチパターンがないかスキャンします：

非同期コンテキストでの同期的なブロッキング：

grep -rn "fs\.readFileSync\|execSync\|spawnSync\|sleep\|time\.Sleep" \
  --include="*.js" --include="*.ts" --include="*.go" . 2>/dev/null | head -10

ページネーションの欠如（上限のないクエリ）：

grep -rn "\.all\b\|find_all\|SELECT \*\b" \
  --include="*.rb" --include="*.py" --include="*.js" --include="*.ts" . 2>/dev/null | head -10

ループ内での高コストな呼び出しの繰り返し：

grep -rn "each\|forEach\|for " \
  --include="*.rb" --include="*.py" --include="*.js" --include="*.ts" . 2>/dev/null | head -20

問題が見つかった各ファイルについて、該当箇所の前後を読み、影響を評価します。

Step 5: 応答時間の目標

以下のしきい値に照らして、調査結果を評価します：

指標	良好	許容範囲	修正が必要
DB クエリの平均時間	<10ms	<100ms	>100ms
リクエストあたりの DB 呼び出し回数	≤3	≤10	>10
エンドポイントの応答時間	<100ms	<500ms	>500ms
バックグラウンドジョブの実行時間	<1s	<30s	>30s

Step 6: ボトルネックのレポート

## Performance Profile Report

### DB Layer
- Slowest query: <query> — Xms mean (Y calls/min)
- Total DB time as % of request: Z%
- Queries over 100ms: N

### Application Layer
- Blocking calls found: X
- Unbounded queries (no LIMIT): Y
- Loops with expensive operations: Z

### Top 3 Bottlenecks (by estimated impact)
1. <bottleneck> — estimated Xms saved per request
2. <bottleneck> — estimated Yms saved per request
3. <bottleneck> — estimated Zms saved per request

### Recommended profiling tools for this stack
- <tool 1>
- <tool 2>

「上位のボトルネックを修正しますか？ それとも、変更前後を計測できるようにプロファイリング用のインストルメンテーションを設定しますか？」と尋ねます。