Percentile latency

GPT-4.icon

🧠 基本の概念

全体の50%のリクエストがこの時間以下で完了している

よく「中央値」として使われる

90%のリクエストがこの時間以下

99%のリクエストがこの時間以下

「ほとんどのリクエストがこの時間までに返ってきてる」ことを意味する

---

📊 なぜ使うのか？

平均（mean）だけを見ると、一部の遅いリクエストに引きずられて全体の印象が歪むことがあります。

一方、パーセンタイルを使うと、実際の体感に近い分布を掴むことができます。

平均：一部の異常値（outlier）に弱い

パーセンタイル：ユーザーの大多数がどんな体験をしているかを把握できる

🛠 例

あるAPIのレスポンス時間が以下のようだったとします：

table:table

リクエスト レイテンシ (ms)

------------ -----------------

平均 → (100 + 110 + 120 + 130 + 1000) / 5 = 292 ms

P50 → 3番目に速い = 120 ms

P90 → 90% = 4.5番目 → 補間して ~700 ms

P99 → サンプル少なすぎて意味なし（実務では数千〜数百万リクエストで計算）

📈 例：p50が3秒、p95が20秒の場合

p50 = 3秒

→ 全体の50%のリクエストが3秒以内で完了している

→ 多くのユーザーにとってはある程度スムーズな応答時間

p95 = 20秒

→ 全体の95%のリクエストが20秒以内で完了している

→ 一部のリクエストが極端に遅くなっている

この2つを比較すると、中央値と95パーセンタイルの間に大きなギャップ（17秒）があることがわかる。

🧠 解釈のポイント：

大多数のユーザーは問題ないように見えても、一部ユーザーは深刻な遅延に直面している可能性

レイテンシのばらつきが大きく、パフォーマンスが安定していない状態

🔍 想定される原因例：

特定条件でのみ発生する重処理

外部サービス依存やネットワークの不安定さ

インフラ側の一時的な負荷集中　など

📌 実務での活用：

p50だけではなく、p95やp99を併せて確認することで、ユーザー体験の「落とし穴」を見逃さない

SLOやアラート設定にもパーセンタイルを活用し、一部の遅延が無視されないように設計する

💡 補足：どう使う？

P99 latencyが悪いと「一部のユーザーがすごく遅い」

P50 latencyが悪いと「半数のユーザーにとって遅い」

SLA（Service Level Agreement）やSLO（Objective）を定義する際によく使われます

🚧 注意点

単純に全リクエストを記録してソートするのは、スケールしない