mcpField
H
http-load-profiler

http-load-profiler

github.com/zebbernテスト・品質4.7k42 回インストール1 日前に更新
リポジトリ

http-load-profiler について

HTTP サービスを段階的な同時実行数で負荷テストし、性能の変化点を調べる Python スキルです。レイテンシ、スループット、エラー率を分析したい開発者向けです。

主な機能

  1. 01wrk または ab の選択
  2. 02同時実行数の段階設定
  3. 03p50・p90・p99 レイテンシ計測
  4. 044 種類の性能変化点検出
  5. 05最適な同時実行数の提案
  6. 06テキストまたは JSON 出力

活用シーン

  1. 01HTTP エンドポイントの段階的な負荷測定
  2. 02レイテンシが急増する同時実行数の特定
  3. 03負荷段階ごとのスループットとエラー比較

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/zebbern/claude-code-guide --skill http-load-profiler

インストール後、Claude Code で/http-load-profilerを入力して読み込まれたか確認します。

同梱ファイルLICENSEscripts/http_benchmark.py

詳細

HTTP 負荷プロファイラー — 段階的な同時実行負荷テストと変曲点分析

HTTP サービスに対して段階的な同時実行負荷テストを実行し、レイテンシのパーセンタイルを自動収集して、パフォーマンスの変曲点を検出します。

特長

  • 2 種類のエンジンに対応:wrk(優先)または ab(Apache Bench)を自動検出します。手動での指定も可能です
  • 段階的な同時実行:ユーザー定義の同時実行レベル(デフォルト:1 → 10 → 50 → 100 → 200 → 500)を順に引き上げます
  • レイテンシのパーセンタイル:各レベルで p50/p90/p99 のレイテンシを収集します
  • 変曲点の検出:パフォーマンスの変曲点を 4 種類、自動的に検出します
    • p99 レイテンシの増加が加速(増加幅が前のステップの増加幅の 2 倍を超える)
    • スループット効率が大幅に低下(接続あたりの RPS が 40% を超えて低下)
    • レイテンシが急上昇する一方でスループットが飽和(RPS の増加が 10% 未満、p99 の増加が 50% を超える)
    • エラー率が急上昇(1% を超え、前のステップの 2 倍になる)
  • 最適な同時実行数の推奨:変曲点に基づいて、最適な同時実行レベルを自動的に提案します
  • Python 依存関係なし:標準ライブラリのみで実装されています

クイックスタート

# Basic usage — run default stepped load test against target URL
python3 scripts/http_benchmark.py https://example.com/api/health

# Custom concurrency steps and duration per step
python3 scripts/http_benchmark.py https://example.com/api/health -s 5,20,50,100,300 -d 15

# Specify ab as the engine
python3 scripts/http_benchmark.py https://example.com/ -t ab

# JSON-only output (for programmatic parsing)
python3 scripts/http_benchmark.py https://example.com/api/health --json

# Use ab with a specific number of requests per step
python3 scripts/http_benchmark.py https://example.com/ -t ab -n 5000

# Save JSON report to a file
python3 scripts/http_benchmark.py https://example.com/api/health --json > report.json

パラメーター

パラメーター短縮形デフォルト説明
url—(必須)対象 URL(http:// または https://)
--steps-s1,10,50,100,200,500同時実行ステップ(カンマ区切りの正の整数)
--duration-d10ステップごとの実行時間(秒)。wrk ではこの値を直接使用し、ab ではこの値からリクエスト数を推定します
--requests-nconcurrency×100ab 使用時のステップごとの総リクエスト数
--tool-t自動検出負荷テストツールを指定します:wrk または ab
--threads—min(concurrency, CPU cores)wrk のスレッド数
--json—falseJSON のみを出力します

出力形式

人間が読みやすい形式(デフォルト)
Tool: wrk
Target URL: https://example.com/api/health
Concurrency steps: [1, 10, 50, 100, 200, 500]
Duration per step: 10s

----------------------------------------------------------------------------------
  Conc. |        RPS |  Avg(ms) |  P50(ms) |  P90(ms) |  P99(ms) |   Errors | Inflection
----------------------------------------------------------------------------------
     1 |      245.3 |      4.1 |      3.8 |      5.2 |      8.1 |   0.00% |
    10 |     2301.5 |      4.3 |      4.0 |      5.8 |      9.3 |   0.00% |
    50 |     9876.2 |      5.1 |      4.6 |      7.2 |     12.5 |   0.00% |
   100 |    14523.1 |      6.9 |      5.8 |     10.3 |     22.7 |   0.00% |
   200 |    15102.3 |     13.2 |     10.1 |     22.5 |     58.3 |   0.12% |  ◀
   500 |    14890.5 |     33.6 |     28.3 |     55.2 |    132.1 |   1.35% |  ◀
----------------------------------------------------------------------------------

Inflection point analysis:
  ▶ Concurrency 200:
    - p99 latency accelerating: 22.7ms → 58.3ms (increase 35.6ms, previous step increase 10.2ms)
    - Throughput saturated with latency spike: RPS grew only 3.9% while p99 latency grew 156.8%
  ▶ Concurrency 500:
    - Error rate surging: 0.12% → 1.35%

Recommended optimal concurrency: 100
JSON 形式(--json)
{
  "url": "https://example.com/api/health",
  "tool": "wrk",
  "duration_per_step": 10,
  "steps": [
    {
      "concurrency": 1,
      "rps": 245.3,
      "avg_latency_ms": 4.1,
      "p50_ms": 3.8,
      "p90_ms": 5.2,
      "p99_ms": 8.1,
      "total_requests": 2453,
      "errors": 0
    }
  ],
  "inflection_points": [
    {
      "concurrency": 200,
      "step_index": 4,
      "reasons": ["p99 latency accelerating: ..."]
    }
  ],
  "recommended_concurrency": 100
}

前提条件

wrk または ab の少なくとも 1 つをインストールする必要があります。

# Ubuntu / Debian
sudo apt-get install wrk          # recommended
sudo apt-get install apache2-utils # ab

# macOS
brew install wrk
# ab is pre-installed on macOS

変曲点検出アルゴリズム

同時実行レベルごとに、以下のメトリクスを直前の 2 つのレベルと比較します。

  1. p99 レイテンシの加速:現在の p99 の増加幅が、前のステップの増加幅の 2 倍を超えると検出します
  2. スループット効率:接続あたりの RPS が前のステップから 40% を超えて低下すると検出します
  3. 飽和の検出:RPS の増加が 10% 未満で、p99 の増加が 50% を超えると検出します
  4. エラー率:エラー率が 1% を超え、前のステップの 2 倍になると検出します

推奨される最適な同時実行数:最初の変曲点より 1 つ前の同時実行レベルです。変曲点が見つからない場合は、RPS が最も高いレベルを選択します。

重要な注意事項

  • 負荷テストでは対象サービスに実際のトラフィックが発生します。許可なく本番サービスに対して実行しないでください
  • wrk は ab より正確なレイテンシのパーセンタイルを提供します(wrk は HdrHistogram を使用します)
  • ab は実行時間パラメーターに対応していません。スクリプトでは総リクエスト数を使って実行時間を近似します
  • 安定した結果を得るには、各ステップを最低 10 秒実行することを推奨します

コメント