陶炳哲 — APRIL 09, 2015
爲何響應時間常被測錯
響應時間在許多情況下都是性能分析的基礎。它們處於預期的界限內時，一切正常；而一旦過高，我們就得開始優化應用。
因此響應時間在性能監測和分析中扮演着核心角色。在虛擬化和雲環境中，它們也是您能得到的最準確的性能指標。但很多情況下，人們卻以錯誤的方式測量並解釋響應時間。爲此我們有充足的理由來討論響應時間測量以及如何對其進行解釋這一話題。下面我將討論典型測量手段、相關的誤解以及如何改善測量手段等問題。
信息被平均丟了
在測量響應時間時，我們無法逐個查看測量結果。即便是在非常小的生產系統中，事務數量也多到難以應付。因此測量結果都要在某一時間框架內彙總到一起。按照應用配置的不同，這可能是幾秒、幾分甚至幾小時。
儘管這種彙總幫助我們輕鬆理解大型系統中的響應時間，但也意味着我們丟失了信息。最常見的測量彙總方法是採用平均值。這就是說所採集到的測量結果被平均到一起，這樣我們處理的就是平均值，而非真實值。 平均值的問題在於它們在很多情況下並沒有反映真實世界中發生的情況。使用平均值時，之所以會引起錯誤或者誤導性結果，主要原因共有兩個。
如果測量結果取值波動較大，那麼平均值無法代表實際測量的響應時間。如測量結果的範圍介於1 到 4 秒之間，那麼平均值可能是在 2 秒左右，這當然並不代表很多用戶的感受。 因此平均值僅對真實世界的性能提供了很少的幫助。所以不應該只使用平均值，而應使用百分位數。如果您與那些在性能領域工作過一段時間的人們交流，他們會告訴你用起來可靠的唯一指標就是百分位數。與平均值相反，百分位數定義了有多少用戶體會到的響應時間低於某一門限值。舉例來說，如果第 50 百分位數爲 2.5 秒，則意味着對於百分之 50 的用戶，響應時間都小於或者等於 2.5 秒。可以看出，這種手段與平均值相比更接近於現實。
測量結果序列的百分位數和平均值
百分位數唯一的潛在缺陷是它們要求的數據存儲量要高於平均值。平均值計算僅要求所有測量結果的總和以及數量，而百分位數的計算卻更爲複雜，它要求整個範圍內的測量結果取值。正是由於這個原因，並不是所有性能管理工具都支持百分位數。
所有東西都被混到一起
數據彙總中另一個重要問題是就是採用哪些數據作爲彙總依據。如果把不同事務類型的數據混合到一起，比如起始頁、查找和信用卡確認，那麼結果就鮮有價值，原因就在於基礎數據的差別就像蘋果和桔子一樣。因此除了確保使用百分位數外，還有必要正確拆分事務類型，以使計算所依據的數據能夠匹配到一起。
按照業務功能來拆分事務的概念通常被稱爲自定義事務。雖然自定義事務基本理念就是通過一些請求參數來區分應用中的事務，這些參數例如這些事務是幹什麼的或者來自哪裏，或者按照邏輯關係讓用戶有選擇的對事務進行聚合等。比如說“放入購物籃”事務或者某一用戶的請求等。
只有綜合兩種手段才能確保所測響應時間構成性能分析的可靠基礎。
本文作者系OneAPM工程師陶炳哲 ，想閱讀更多好的技術文章，請訪問OneAPM官方技術博客。