深入解析:p95、p99 與 Apdex 怎麼讀

把 100 筆 response time 排序,p95 = 第 95 筆,意思是「95% 的請求都比這個快」。平均值會被少數異常值大幅拉動,但對使用者體驗來說,最慢的那 5% 才是會抱怨的人。

舉個例子:99 筆都是 100ms、1 筆是 10000ms,平均 = 199ms 看起來很好,但 p99 = 10000ms 才反映真實有 1% 的人等了 10 秒。SLO 用平均值定 → 永遠不會超標、永遠不會修最該修的問題。

Apdex 把每筆請求分三類:滿意(< T)、容忍(T ~ 4T)、挫敗(> 4T)。公式:(滿意數 + 容忍數 / 2) / 總數,範圍 0~1。

業界常用的 T 值:

• API 後端:T = 200~500ms
• 網頁初始載入:T = 1s(對應 LCP 推薦值)
• 互動類請求(form submit、search):T = 500ms
• 重型操作(報表、檔案上傳):T = 3~5s

Apdex < 0.7 通常代表使用者體驗開始顯著惡化,< 0.5 代表大多數請求落在容忍區之外。

平穩型:p50 / p90 / p95 接近,例如 120 / 180 / 200ms。系統健康,沒有 outliers。

長尾型:p50 = 200ms 但 p95 = 2000ms。多數請求很快,但有少數慢請求。常見原因:DB 慢查詢、外部 API 偶爾超時、GC 停頓。優先處理:找出長尾再優化,降平均值幾乎沒用。

雪崩型:p50 / p90 / p95 全部一起拉高,例如 800 / 1500 / 3000ms。系統整體飽和,通常是 CPU / 連線池打滿。處理方式:加機器或限流。

1. 樣本數太少還算 p99:n = 100 算 p99 是抓最慢那一筆,單一 outlier 就會跳。p99 建議至少 1000 筆樣本才有統計意義。

2. 用平均值定 SLO:幾乎所有 SLO 業界標準(Google SRE Book、AWS Well-Architected)都用 p95 / p99,不用平均。

3. 忘了標 percentile 演算法:linear interpolation(R-7,Excel / 本工具預設)跟 nearest-rank(R-1)在小樣本下會差幾 ms。報告裡標清楚用哪種。

4. 跨時段比較沒對齊樣本數:深夜 100 筆樣本的 p99 vs 尖峰 10000 筆樣本的 p99 沒有可比性,要先把樣本切成相同大小或固定時間窗。

把這個工具當作「分析單次測試結果」的快速通道,長期監控應該丟到 Grafana / Datadog / New Relic 等。在那些工具裡設 alert 規則:

• p95 > 500ms 持續 5 分鐘 → Slack 通知
• Apdex < 0.7 持續 10 分鐘 → PagerDuty 叫起來

JMeter / k6 跑完後丟結果到本頁快速看一眼,如果指標已經爆掉、再去深入翻 Grafana 找原因 — 這是日常 QA / SRE 流程。