パーセンタイルレイテンシ（p95・p99）

パーセンタイルレイテンシは、応答時間を平均ではなく順位で表します。p95 とは、95% のリクエストがその値以下で完了した値であり、それより時間がかかったのは最も遅い 5% だけです。p50 は中央値で、典型的な体験を表します。p99 や p99.9 はテール、つまり最も遅いリクエストを表し、ユーザーが気づいて不満を持つのはたいていこの部分です。

パーセンタイルが平均より優れている理由

100 件のリクエストのうち、90 件が 100 ms、10 件が 2,000 ms かかったとします。

統計値	値
平均	290 ms
p50（中央値）	100 ms
p95	2,000 ms
p99	2,000 ms

平均の 290 ms は、実際に発生したどのリクエストも表していません。許容範囲に見えますが、実際には 10 人に 1 人のユーザーが 2 秒待たされています。パーセンタイルなら、大半のリクエストは速く、テールは非常に遅いという両方の事実がわかります。また平均は少数の極端な外れ値に大きく引っ張られますが、中央値はそうなりません。

テールは見た目以上に重要です。1 回のページ読み込みで多数のバックエンド呼び出しが発生することが多く、1 回のユーザーセッションには多数のページ読み込みが含まれます。そのため、かなりの割合のユーザーが、訪問中に少なくとも 1 回は p99 並みに遅いリクエストに遭遇します。

テストでのパーセンタイルの使い方

性能目標やゲートはパーセンタイルで記述すべきです。k6 では次のようになります。

export const options = {
  thresholds: {
    http_req_duration: ['p(50)<200', 'p(95)<500', 'p(99)<1500'],
  },
};

複数のパーセンタイル（p50、p95、p99、最大値）をまとめて、スループットやエラー率とあわせて報告しましょう。それぞれが異なる側面を伝えてくれます。

よくある間違い

• パーセンタイルを平均する。 10 台のサーバーの p95 の平均は、全体の p95 ではありません。パーセンタイルは、統合した生データか、マージ可能なヒストグラムから計算する必要があります。
• サンプルが少なすぎる。 200 件のリクエストから求めた p99 は、2 つのデータ点に基づいているにすぎません。テール部分に意味のある件数が集まるまで十分長く実行しましょう。
• エラーを無視する。 5 ms で即座に失敗するリクエストは、レイテンシを実際より良く見せることがあります。レイテンシは必ずエラー率と並べて読みましょう。
• 協調的欠落（coordinated omission）。 遅いレスポンスを待ってから次のリクエストを送る負荷ツールは、速度低下中に送るリクエストが知らないうちに少なくなり、テールレイテンシを過小評価します。到着レート（オープンモデル）方式の負荷生成でこれを軽減できます。