平均值 vs 百分比

在考慮要性能測(cè)試的目標(biāo)值時(shí)，我們需要考慮用什么統(tǒng)計(jì)口徑。大多數(shù)人都會(huì)首選平均值，但在大多數(shù)情況下，這個(gè)正確的，但你也應(yīng)該適當(dāng)?shù)目紤]百分?jǐn)?shù)。但你有可用性的要求，作為性能測(cè)試的目標(biāo)里肯定會(huì)有用百分比作的要求。舉個(gè)栗子：“數(shù)據(jù)庫(kù)請(qǐng)求的平均延遲必須小于10ms，95%是請(qǐng)求必須小于100ms”
。。。（這里我省略了對(duì)“95%是請(qǐng)求必須小于100ms”的翻譯說(shuō)明，我覺(jué)得中國(guó)的程序猿應(yīng)該看得懂我翻譯的那句話）

1，2，2，4，5，5，8，10，10，11，11，11，15，23，24，25，50，87

舉個(gè)栗子，上面有18個(gè)測(cè)試下來(lái)的值（已經(jīng)過(guò)排序了的），的平均耗是17ms，但有5%的訪問(wèn)超過(guò)50ms。如果你剛好只看平均值，你一定會(huì)認(rèn)為一切正常。但當(dāng)你用了百分比作為指標(biāo)，你就會(huì)知道一些偶發(fā)的GC操作會(huì)影響到你的訪問(wèn)質(zhì)量。

百分比是高可用性的最重要指標(biāo)。如果你需要更高的可靠性，就需要提出一個(gè)更高的百分?jǐn)?shù)指標(biāo)。通常來(lái)說(shuō)99%已經(jīng)很好了，但你還會(huì)可能有99.99% 99.999%，甚至更高的指標(biāo)，但通常來(lái)說(shuō)，決定采用這些指標(biāo)數(shù)字取決于業(yè)務(wù)，而不是開發(fā)。

這里作為翻譯的我，來(lái)補(bǔ)一些關(guān)于百分比的數(shù)據(jù)
99% 允許每年服務(wù)器掛 3.65 天（多讓人尷尬的數(shù)據(jù)啊，但我相信很多公司服務(wù)器不一定達(dá)能到這個(gè)要求）
99.9% 允許每年掛 8.76 小時(shí)（1年出了一次較大的事故，基本就用完額度了）
99.99% 允許每年掛 52.6 分鐘（1年只能出一次小的事故，還得是能立即解決的）
99.999% 允許每年掛 5.26 分鐘（如果真的發(fā)生小于這個(gè)時(shí)間的事故，對(duì)于用戶來(lái)說(shuō)一般很難有感知，但是在淘寶雙十一零點(diǎn)之后的一個(gè)小時(shí)內(nèi)碰上的話 (=@__@=) ）
99.9999% 允許每年掛 31 秒（寫一個(gè)程序在一年的時(shí)間里只往控制臺(tái)輸出 hello world的同時(shí)還得祈求上帝保證機(jī)房不要斷電 O(∩_∩)O！）

百分比是一個(gè)重要的指標(biāo)，是因?yàn)樗梢詭椭懔私饽愕南到y(tǒng)，即使通過(guò)平均值觀察到，你的系統(tǒng)一切正常，但是只有90%的用戶訪問(wèn)滿足了目標(biāo)，也會(huì)意味著，你還有10%的用戶訪問(wèn)還有可以改進(jìn)的空間。要解決這這部分請(qǐng)求問(wèn)題，需要的更多是商業(yè)上的考量，因?yàn)檫@里會(huì)存在一個(gè)遞減回報(bào)的問(wèn)題，因?yàn)樘嵘詈蟮?%要花的時(shí)間不是一般的多。

對(duì)于上面的例子“有95%的訪問(wèn)請(qǐng)求滿足了50ms以內(nèi)的需求”，但數(shù)據(jù)源來(lái)說(shuō)，不符合統(tǒng)計(jì)學(xué)上對(duì)樣本數(shù)量的要求，至少要要相同數(shù)量級(jí)的樣本才行。要描述 99% 需要統(tǒng)計(jì)100個(gè)樣本，要描述 99.9% 則至少要1000個(gè)樣本，并以此類推。

再舉一個(gè)作為翻譯我的栗子
話說(shuō)當(dāng)年做的頁(yè)游上線，在開服到了幾百人（>500）的時(shí)候玩家會(huì)覺(jué)得比較卡，登陸服務(wù)器看了一下cpu和網(wǎng)絡(luò)情況都不是很高（<30%)，內(nèi)存占也沒(méi)啥問(wèn)題。經(jīng)過(guò)后來(lái)多方努力，發(fā)現(xiàn)是用戶首次進(jìn)入游戲時(shí)，為了數(shù)據(jù)安全，這時(shí)候初始化數(shù)據(jù)庫(kù)的操作是同步的，而不是異步的。再加上dogse引擎的限定，主邏輯是跑在單線程的隊(duì)列上，這就導(dǎo)致開服時(shí)主線程的阻塞會(huì)比較嚴(yán)重。每個(gè)玩家卡個(gè)200ms，同時(shí)有3個(gè)玩家進(jìn)入，剩下的玩家自然會(huì)覺(jué)得卡了。

對(duì)于本書最重要的，而起是要重復(fù)說(shuō)三遍的觀點(diǎn)是：

測(cè)量，測(cè)量，測(cè)量

你要知道，如果沒(méi)有準(zhǔn)確的測(cè)量，在解決性能相關(guān)問(wèn)題時(shí)，你只能按照自己的經(jīng)驗(yàn)和感覺(jué)來(lái)判斷那里有性能問(wèn)題。這會(huì)存在2個(gè)問(wèn)題：
首先：假設(shè)你的感覺(jué)是對(duì)的，找到了一個(gè)性能問(wèn)題的地方，但你不知道當(dāng)你修改了這里后，對(duì)性能提升了多少
其次：我也不可能告訴你那里經(jīng)常犯錯(cuò)了。舉個(gè)栗子（這個(gè)栗子我沒(méi)看懂）：在分析一個(gè)應(yīng)用占用里很多非托管內(nèi)存的問(wèn)題，我們最初假設(shè)是認(rèn)為在某處加載了一個(gè)很大的數(shù)據(jù)。隨后安排開發(fā)人員做排查工作，通過(guò)禁止某些組件的加載，還調(diào)試了轉(zhuǎn)儲(chǔ)過(guò)程（dump)里堆的數(shù)據(jù)。結(jié)果讓我們很吃驚，大部分內(nèi)存的開銷來(lái)自于組件（Assembly）加載，而不是我們之前所想的數(shù)據(jù)加載

如果沒(méi)有工具做測(cè)量，那么性能優(yōu)化就是沒(méi)意義的。性能優(yōu)化是一個(gè)連續(xù)的過(guò)程，你需要有自己的工具來(lái)對(duì)這個(gè)過(guò)程做記錄。下面的章節(jié)將介紹一些常見(jiàn)的工具。恩大部分是免費(fèi)的，有一款收費(fèi)的，但是是vs專業(yè)版附帶的，所以你懂的。

相關(guān)文章：

• [翻譯]編寫高性能 .NET 代碼 第一章：性能測(cè)試與工具 -- 選擇什么來(lái)衡量
  

原文地址：http://www.cnblogs.com/yahle/p/6530827.html

---

.NET社區(qū)新聞，深度好文，微信中搜索dotNET跨平臺(tái)或掃描二維碼關(guān)注

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的[翻译]编写高性能 .NET 代码 第一章：性能测试与工具 -- 平均值 vs 百分比的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。