jmeter分析性能報告時的誤區

概述

咱們用jmeter作性能測試，必然須要學會分析測試報告。可是初學者經常由於對概念的不清晰，最後被測試報告帶到溝裏去。

 

常見的誤區

• 分析響應時間全用平均值
• 響應時間不和吞吐量掛鉤
• 響應時間和吞吐量不和成功率掛鉤

。。。。。

 

平均值特別不靠譜

平均值爲何不靠譜？相信你們讀新聞的時候常常能夠看到，平均工資，平均房價，平均支出，等等字眼，你就知道爲何平均值不靠譜了。

（這些都是數學遊戲）

性能測試也同樣，平均數也是不靠譜，推薦一篇詳細的文章《Why Averages Suck and Percentiles are Great》

咱們作性能測試時，獲得的結果數據不會老是同樣的，而是波動的。

若是算平均值就會出現這樣的狀況：測試了10次，有9次是1ms，而有1次是10s，那麼平均數據就是1s。

很明顯，這徹底不能反應性能測試的實際狀況，由於那個10s的請求就是一個不正常的值。

另外，中位數（Median）可能會比平均數要稍微靠譜一些，中位數的意就是把將一組數據按大小順序排列，處在最中間位置的一個數叫作這組數據的中位數 ，這意味着有50%的數據低於或高於這個中位數。

最爲正確的統計作法是用百分比分佈統計。TP50的意思是50%的響應時間都小於某個值，TP90表示90%的響應時間小於某個值。

咱們有一組數據：[ 10ms,  1s, 200ms, 100ms]，咱們把其從小到大排個序：[10ms, 100ms, 200ms, 1s]。

因而咱們知道，TP50，就是50%的請求ceil(4*0.5)=2時間是小於100ms的，TP90就是90%的請求ceil(4*0.9)=4時間小於1s。

因而：TP50就是100ms，TP90就是1s

所以，一般嚴格一點的響應時間要求是這樣的：99%的請求必須小於XXms

 

響應時間務必和吞吐量（Thoughput）掛鉤

系統的性能若是隻看吞吐量，不看響應時間是沒有意義的。

個人系統tps能夠達到10000，可是響應時間已經到了20秒鐘，這樣的系統已經不可用了，吞吐量也是沒有意義的。

當負載上升的時候，系統會逐漸變的不穩定，響應時間也會變得愈來愈慢，波動愈來愈大，而吞吐率卻開始降低，包括CPU的使用率狀況也會如此。

因此，當系統變得不穩定的時候，吞吐量已經沒有意義了。

 

因此，吞吐量的值必需配合響應時間來看。例如：TP99小於100ms的時候，系統能夠承載的最大併發數是1000。

 

響應時間吞吐量和成功率要掛鉤

應該不難理解，若是請求都是錯誤的，還作什麼性能測試。

好比，我說個人系統併發能夠達到10萬，可是失敗率是50%，那麼這10萬的併發徹底就是一個笑話。

性能測試的失敗率的容忍是很是低的。對於一些關鍵系統，成功率必須在100%