平均值 vs 百分比

在考慮要性能測試的目標值時，我們需要考慮用什么統計口徑。大多數人都會首選平均值，但在大多數情況下，這個正確的，但你也應該適當的考慮百分數。但你有可用性的要求，作為性能測試的目標里肯定會有用百分比作的要求。舉個栗子：“數據庫請求的平均延遲必須小于10ms，95%是請求必須小于100ms”
。。。（這里我省略了對“95%是請求必須小于100ms”的翻譯說明，我覺得中國的程序猿應該看得懂我翻譯的那句話）

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

舉個栗子，上面有18個測試下來的值（已經過排序了的），的平均耗是17ms，但有5%的訪問超過50ms。如果你剛好只看平均值，你一定會認為一切正常。但當你用了百分比作為指標，你就會知道一些偶發的GC操作會影響到你的訪問質量。

百分比是高可用性的最重要指標。如果你需要更高的可靠性，就需要提出一個更高的百分數指標。通常來說99%已經很好了，但你還會可能有99.99% 99.999%，甚至更高的指標，但通常來說，決定采用這些指標數字取決于業務，而不是開發。

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

百分比是一個重要的指標，是因為他可以幫助你了解你的系統，即使通過平均值觀察到，你的系統一切正常，但是只有90%的用戶訪問滿足了目標，也會意味著，你還有10%的用戶訪問還有可以改進的空間。要解決這這部分請求問題，需要的更多是商業上的考量，因為這里會存在一個遞減回報的問題，因為提升最后的1%要花的時間不是一般的多。

對于上面的例子“有95%的訪問請求滿足了50ms以內的需求”，但數據源來說，不符合統計學上對樣本數量的要求，至少要要相同數量級的樣本才行。要描述 99% 需要統計100個樣本，要描述 99.9% 則至少要1000個樣本，并以此類推。

再舉一個作為翻譯我的栗子
話說當年做的頁游上線，在開服到了幾百人（>500）的時候玩家會覺得比較卡，登陸服務器看了一下cpu和網絡情況都不是很高（<30%)，內存占也沒啥問題。經過后來多方努力，發現是用戶首次進入游戲時，為了數據安全，這時候初始化數據庫的操作是同步的，而不是異步的。再加上dogse引擎的限定，主邏輯是跑在單線程的隊列上，這就導致開服時主線程的阻塞會比較嚴重。每個玩家卡個200ms，同時有3個玩家進入，剩下的玩家自然會覺得卡了。

對于本書最重要的，而起是要重復說三遍的觀點是：

測量，測量，測量

你要知道，如果沒有準確的測量，在解決性能相關問題時，你只能按照自己的經驗和感覺來判斷那里有性能問題。這會存在2個問題：
首先：假設你的感覺是對的，找到了一個性能問題的地方，但你不知道當你修改了這里后，對性能提升了多少
其次：我也不可能告訴你那里經常犯錯了。舉個栗子（這個栗子我沒看懂）：在分析一個應用占用里很多非托管內存的問題，我們最初假設是認為在某處加載了一個很大的數據。隨后安排開發人員做排查工作，通過禁止某些組件的加載，還調試了轉儲過程（dump)里堆的數據。結果讓我們很吃驚，大部分內存的開銷來自于組件（Assembly）加載，而不是我們之前所想的數據加載

如果沒有工具做測量，那么性能優化就是沒意義的。性能優化是一個連續的過程，你需要有自己的工具來對這個過程做記錄。下面的章節將介紹一些常見的工具。恩大部分是免費的，有一款收費的，但是是vs專業版附帶的，所以你懂的。

相關文章：

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

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

---

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。