概述

我們用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%

?

轉載于:https://www.cnblogs.com/Zfc-Cjk/p/11152360.html

總結

以上是生活随笔為你收集整理的jmeter分析性能报告时的误区的全部內容，希望文章能夠幫你解決所遇到的問題。

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