Label：每個 JMeter 的 element（例如 HTTP Request）都有一個 Name 屬性，這里顯示的就是 Name 屬性的值
#Samples：表示你這次測試中一共發出了多少個請求，如果模擬10個用戶，每個用戶迭代10次，那么這里顯示100
Average：平均響應時間——默認情況下是單個 Request 的平均響應時間，當使用了 Transaction Controller 時，也可以以Transaction 為單位顯示平均響應時間。單位ms
Median：中位數，也就是 50％ 用戶的響應時間
90% Line：90％ 用戶的響應時間
Min：最小響應時間
Max：最大響應時間
Error%：本次測試中出現錯誤的請求的數量/請求的總數
Throughput：吞吐量——默認情況下表示每秒完成的請求數（Request per Second），當使用了 Transaction Controller 時，也可以表示類似 LoadRunner 的 Transaction per Second 數
KB/Sec：每秒從服務器端接收到的數據量，相當於LoadRunner中的Throughput/Sec
結論：
1. 90％用戶響應時間在 Jmeter中是可以設置的，你可以改為80％或95％；
設置方法：找到bin目錄下的jmeter.properties文件，修改aggregate_rpt_pct3=99.99，重啟jmeter。
2. 對於這個表，LoadRunner中是沒有直接提供的，你可以把LR中的原始數據導出到Excel中，並使用Excel中的PERCENTILE 函數很簡單的算出不同百分比用戶請求的響應時間分布情況；
3.從上面的表中來看，對於Home Page來說，平均事務響應時間(MEAN)只同70％用戶響應時間相一致。也就是說假如我們確定Home Page的響應時間應該在5秒內，那么從平均事務響應時間來看是滿足的，但是實際上有10-20％的用戶請求的響應時間是大於這個值的；對於Page 1也是一樣，假如我們確定對於Page 1 的請求應該在3秒內得到響應，雖然平均事務響應時間是滿足要求的，但是實際上有20-30％的用戶請求的響應時間是超過了我們的要求的；
4. 你可以在95 th之后繼續添加96/ 97/ 98/ 99/ 99.9/ 99.99 th，並利用Excel的圖表功能畫一條曲線，來更加清晰表現出系統響應時間的分布情況。這時候你也許會發現，那個最大值的出現幾率只不過是千分之一甚至萬分之一，而且99％的用戶請求的響應時間都是在性能需求所定義的范圍之內的；
5. 果你想使用這種方法來評估系統的性能，一個推薦的做法是盡可能讓你的測試場景運行的時間長一些，因為當你獲得的測試數據越多，這個響應時間的分布曲線就越接近真實情況；
6. 在確定性能需求時，你可以用平均事務響應時間來衡量系統的性能，也可以用90％或95％用戶響應時間來作為度量標准，它們並不沖突。實際上，在定義某些系統的性能需求時，一定范圍內的請求失敗也是可以被接受的；