效能工程

百分位/尾端延遲(p99/p999)

/ p99: pee-NINE-ty-nine /

假設一個網路服務平均 5 毫秒處理一個請求。聽起來很棒——但問個不同的問題:在一百萬個請求裡,最慢的那一千個有多慢?如果它們每個花半秒,真實使用者就會經常撞上那半秒,而那令人愉快的平均完全把它藏起來了。百分位延遲就是誠實地問這個問題的工具,而分布的慢端就叫尾端(tail)。

百分位是排序後量測清單裡的一個切點。p50(中位數)是有一半請求落在其下的值;p99 是 99% 的請求贏過的值,所以有 1% 比它慢;p999(也寫成 p99.9)是 99.9% 贏過的值,所以每一千個有一個比它慢。人們說尾端延遲,指的就是這些高百分位——p99、p999、p9999——分布裡靠近慢端極值的那部分。它之所以比平均更重要有兩個原因。第一,延遲分布幾乎從不對稱;它有一條長長的右尾(少數非常慢的事件),對平均的拉扯方式與對百分位不同,所以平均可能遠低於相當比例的使用者實際經歷的——平均在說謊。第二,更微妙地,使用者的單一動作常常「扇出」成許多後端請求,而使用者要等其中最慢的那一個;如果一個頁面發出 100 次後端呼叫,使用者經歷到的延遲大致是單次呼叫的 p99,而非中位數——於是罕見的尾端事件在頁面層級變成了常態。

它之所以重要,是因為服務水準目標、告警、以及使用者感受到的回應性,都是用百分位而非平均寫成的。兩個誠實的警告。你不能跨機器或跨時間窗對百分位取平均:兩台伺服器合起來的 p99「不是」它們兩個 p99 的平均——你必須合併底層的分布(這正是 HdrHistogram 之類直方圖工具存在的原因)。而且量測高百分位需要很多樣本(你無法用 100 個請求估 p999)與一個誠實的框架——見協同遺漏陷阱,它會無聲地讓尾端看起來遠比實際好。

一百萬個請求:平均 5 毫秒、p50 4 毫秒、p99 40 毫秒、p999 480 毫秒。 頁面發出 100 次後端呼叫 -> 使用者等最慢的那個 -> 典型頁面延遲約等於單次呼叫的 p99 約 40 毫秒,而非 5 毫秒。

平均(5 毫秒)對使用者無關緊要:在 100 路扇出下,經歷到的延遲跟著單次呼叫的 p99(40 毫秒)走。

你不能對百分位取平均或相加:多個來源合起來的 p99 需要合併它們完整的分布,而不是對各自的 p99 數字做算術——這個錯誤悄悄毀掉了大多數儀表板。

又称
tail latencyhigh-percentile latencyp50/p99/p999尾端延遲高百分位延遲