文章轉自：原創： 楊建旭 https://mp.weixin.qq.com/s/Y2pE6wDTJ0bma0DXOBTC0g
在實際的生產運行、測試過程中，一般都會關注吞吐量、響應時間、CPU利用率，在開發和測試階段，我們不但需要關注，而且要通過它們之間的關系來驗證測試的結果是否可信、分析性能問題在哪里。
這里先舉一個例子，通過計算，發現測試結果不可信的例子。
該場景是服務器並發處理業務報文，並且達到了最大處理能力（即TPS達到最大，如果再增加壓力，就出現擁堵現象），性能測試結果如下
看了之后結果，我立刻說：這不可能
原因如下：這個場景中TPS=14，一共有20個進程並發處理。那么每個進程每秒鍾處理的業務個數=14/20=0.7個。
那么每個業務的響應時間（理論計算）=1（秒）/0.7=1.43秒。
而測試結果顯示，業務響應時間為240毫秒（0.24秒），這中間的1.42-0.24秒哪里去了？這個結果一定不可信。隨即，我咨詢對於響應時間的統計方式。得到的答復是：統計工具從日志里面統計的。好吧，只能打開原始日志看了。
原始日志中每個業務有5個時間戳，我姑且叫它們ABCDE吧。
A：客戶端發起的時間（按照客戶端的機器時間給打的時間戳）
B：服務器端進程從消息中間件中取出消息的時間
C：服務器端開始處理的時間
D：進程認為自己處理結束的時間
E：寫這一條日志的時間
當前的統計方式是D-C。
問：為什么不是E-B？
答：開發人員說按照D-C
好吧，不扯那么多了，計算吧。
計算幾萬條業務的E-B的平均時間，1573.34毫秒，和我們理論的計算（1.43秒）基本吻合。
所以，之前的統計方法是錯誤的。
舉第二個例子，和CPU利用率相關的例子。
這個例子中，同樣是服務器並發處理某類業務報文，性能測試結果如下：
平均響應時間是198.78毫秒，即0.19878秒。那么每個進程每秒鍾處理的業務個數=1/0.19878=5個。
服務器一共設置了最大20個進程並發處理。那么如果這20個進程都被調用起來全速處理的話，它們的最大處理能力是每秒鍾=20*5=100個。
而當前的TPS=52.46，相當於最大能力（100）的52.46%，那么CPU利用率也應該差不多這個數，我們實測的CPU利用率是56%，考慮隨着TPS的增加，業務響應時間也是會變化的，系統的CPU也不是完全線性變化的，上述的計算推測已經是非常吻合實際情況了。說明這個測試當中，各個系統性能數據之間是可以從數字關系上對上號，說明他們的取值都是正確的。
這里還要多說一點，在虛擬化環境下，大多數人對AIX/Power系統的CPU利用率取值是錯誤的，因此拿起測試結果大致一算，是對CPU利用率取值的快速驗證。虛擬化環境下Power系統的CPU利用率取值我在之前的文章中有過介紹，感興趣的同學可以回看。