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