ベンチマークの作法

よいベンチマークと悪いベンチマーク

ベンチマーク は、システムの性能を定量的に評価する手法です。 しかし、方法論を間違えると「速くなった気がする」だけの無意味な結果になります。 『詳解システムパフォーマンス』第 12 章では、再現性・公平性・統計的妥当性を備えたベンチマークの設計を強調しています。

統計的な厳密さ

信頼できるベンチマーク結果を得るには、以下のプラクティスが必要です。

• ウォームアップ — JIT コンパイル、キャッシュ充填が完了するまでの測定を除外する
• 繰り返し — 最低 30 回以上実行し、平均だけでなく分散を確認する
• パーセンタイル — 平均値ではなく p50, p95, p99 で評価する（外れ値が平均を歪める）

平均レイテンシが良好でも p99 が悪い場合、100 リクエストに 1 回はユーザーが遅延を体験しています。

マイクロベンチマーク vs マクロベンチマーク

マイクロベンチマークは再現性が高い一方、実環境の複合的な負荷パターンを反映しません。 本番に近い条件で計測するマクロベンチマークと組み合わせて評価します。

ツール

# wrk — HTTP ベンチマーク（高スループット）
wrk -t4 -c100 -d30s http://localhost:8000/api/users

# k6 — スクリプタブルな負荷テスト
k6 run --vus 50 --duration 60s load_test.js

Python ベースの Locust はシナリオを Python コードで記述できるため、バックエンドエンジニアに馴染みやすいです。

Coordinated Omission

Coordinated Omission（協調的省略） は、負荷ツールが遅延レスポンスの影響を正しく計測できない問題です。 たとえば「前のリクエストが返るまで次を送らない」設計のツールでは、遅延が発生するとリクエストレートが下がり、レイテンシが実際より良く見えます。 wrk2 や k6 はこの問題を回避するために、固定レートでリクエストを送信する仕組みを持っています。

ベンチマーク結果を評価する際は、ツールがこの問題に対処しているかを必ず確認してください。