1.說明
jmeter工具對於請求的測試結果，有多種形式展現，但是數據比較難懂，現在針對不同的展現做具體的說明。
2.監聽器
（一）圖形結果
(1)樣本數目：總共發到服務器的請求數
(2)最新樣本：服務器響應最后一個請求的處理時間（單位：毫秒）
(3)平均：所有取樣器結果的響應時間平均值（總運行時間除以發送到服務器的請求數）
(4)偏離：服務器響應時間變化，離散程度測量值的大小，即數據的分布。
(5)吞吐量：服務器每分鍾處理的請求數
(6)中值：所有取樣器結果的響應時間中間值（有一半的服務器響應時間低於該值而另一半高於該值）
(7)X軸：取樣器個數的均勻分部軸
(8)y軸：處理時間（單位：毫秒）
（二）聚合報告
聚合報告中的時間單位ms（1000ms=1s）
(1)Label : 每個JMeter 的element(例如HTTP Request)都有一個Name屬性，這里顯示的就是Name屬性的值
(2)#Samples : 表示你這次測試中一共發出了多少請求，如果測試計划模擬10個用戶，每個用戶迭代10次，這里就會顯示100
(3)Average : 平均響應時間，默認情況下是單個Request的平均響應時間，當使用了事務控制器時，也可以以事務為單位顯示平均響應時間
(4)Median : 中位數，也就是50%用戶的響應時間（據按由小到大的順序排列后，取出第50%位）
(5)90%Line : 90%用戶的響應時間（據按由小到大的順序排列后，取出第90%位）
(6)95%Line : 95%用戶的響應時間（據按由小到大的順序排列后，取出第95%位）
(7)99%Line : 99%用戶的響應時間（據按由小到大的順序排列后，取出第99%位）
(8)Min : 最小響應時間
(9)Max : 最大響應時間
(10)Error% : 錯誤率，本次測試中出現錯誤的請求的數量/請求總數
(11)Throughput : 吞吐量，默認情況下表示每秒完成的請求數(Request per Second)
(12)KB/Sec : 每秒從服務器端接受到的數據量（單位：千字節/秒）
(13)Received KB/sec----每秒從服務器端接收到的數據量（單位：千字節/秒）
(14)Sent KB/sec----每秒從客戶端發送的請求的數量（單位：千字節/秒）
（三）用表格查看結果
(1)Sample:每個請求的序號
(2)start time:每個請求開始時間
(3)thread name:每個線程組名稱
(4)label：請求類型，對應在測試計划下填寫的請求名稱
(5)Sample time：每個請求所花時間，單位毫秒（0.001秒(s)=1毫秒(ms) 1秒(s)=1000毫秒(ms) ）
(6)Status：請求狀態，如果為 √ 則表示成功，如果為 × ，則表示失敗。
(7)Bytes：響應的字節數，請求的字節數。
(8)Sent Bytes：發送的字節數。
(9)Latency：延遲的時間，等待時長。（單位：毫秒）
(10)Connect Time(ms)：連接服務器的時間。（單位：毫秒）
(11)樣本數目：所有請求個數，樣本數目 = 線程數（請求用戶數）* 請求次數 。（單位：個）
(12)最新樣本：最新樣本響應時間，表示服務器響應最后一個請求的時間。（單位：毫秒）
(13)平均：所有請求的平均響應時間。（單位：毫秒）
(14)偏離：服務器響應時間變化、離散程度測量值的大小，或者，換句話說，就是數據的分布。（偏離值是一個觀察測試環境和系統穩定性的數據）
3.名詞解釋及分析
偏離值：偏離值是一個觀察測試環境和系統穩定性的數據。偏離值越小則環境越穩定，所測得的數據越有效，反之，如果偏離值太大則說明環境不穩定，在這種情況下測得的數據就沒什么價值，所以在測試的時候，必須要保證偏離值是小的。（可參考：http://blog.sina.com.cn/s/blog_5034424d010080ay.html）
吞吐率：單位時間內服務器處理的請求數來描述其並發處理能力。吞吐率，是單位時間內網絡上傳輸的數據量，特指web服務器單位時間內處理的請求數。吞吐率是衡量網絡性能的重要指標。通常情況下，吞吐率用“字節數/秒”來衡量。也可以用“請求數/秒”來衡量。吞吐量除以時間，所得到的單位時間內的數據量就是吞吐率。吞吐率代表着單位時間內所能承受的壓力，是測試中一個重要的指標。通過比較吞吐量，可以發現系統的運行狀態。當隨着並發數增加時，吞吐率是不斷增加的，當達到一個服務器極限后，再增加並發數，吞吐率會急速下降，直至服務器崩潰。所以，當達到臨界點（吞吐量最高點，負載和處理均衡時）為“最大吞吐率”，是系統在運行下的一個理想閾值范圍。
備注：一個請求還是一個頁面，它的本質都是在網絡上傳輸的數據，那么用來表述數據的單位就是字節數。
吞吐量：是指在一次性能測試過程中，網絡上傳輸的數據量的總和。對於交互式應用來說：吞吐量指標反映的是服務器承受的壓力。在容量規划的測試中：吞吐量是一個重點關注的指標，因為它能夠說明系統級別的負載能力。另外，在性能調優過程中，吞吐量指標也有重要的價值。
比如：一個大型工廠，他們的生產效率與生產速度很快，一天生產10W噸的貨物，結果工廠的運輸能力不行，就兩輛小型三輪車一天拉2噸的貨物，說明的是這個運輸能力（吞吐量）是整個系統的瓶頸。
只用吞吐量來衡量一個系統的性能（輸出能力）是極其不准確的。
用個最簡單的例子說明，一個水龍頭開一天一夜，流出10噸水；10個水龍頭開1秒鍾，流出0.1噸水。此時當然是一個水龍頭的吞吐量大。但是，你能說1個水龍頭的出水能力是10個水龍頭的強嗎？顯然不能。
所以，我們要加單位時間，看誰1秒鍾的出水量大，這就是吞吐率
TPS：事務(Transaction Per second),就是用戶某一步或幾步操作的集合。每秒鍾用戶向web服務器提交的HTTP請求數。同時，要保證它有一個完整意義。每秒鍾系統能夠處理事務或交易的數量，它是衡量系統處理能力的重要指標。這個指標是web 應用特有的一個指標；web應用是“請求-響應”模式，用戶發一個申請，服務器就要處理一次，所以點擊是web應用能夠處理的交易的最小單位。如果把每次點擊定義為一個交易，點擊率和TPS就是一個概念。點擊率越大，對服務器的壓力也越大，點擊率只是一個性能參考指標，重要的是分析點擊時產生的影響。
點擊率：可以看做是TPS的一種特定情況。更能體現用戶端對服務器的壓力。
TPS：更能體現服務器對客戶請求的處理能力。
比如：用戶對某一個頁面的一次請求，用戶對某系統的一次登錄，淘寶用戶對商品的一次確認支付過程。這些我們都可以看作一個事務。
吞吐量，吞吐率的意義：
- 吞吐量的限制是性能瓶頸的一種重要表現形式，因此，有針對地對吞吐量設計測試，可以協助盡快定位到性能冰晶所在的位置。
- 80%系統的性能瓶頸都是由吞吐量制約。
- 並發用戶和吞吐量瓶頸之間存在一定的關聯。
- 通過不斷增加並發用戶數和吞吐量觀察系統的性能瓶頸。然后，從網絡、數據庫、應用服務器和代碼本身4個環節確定系統的性能瓶頸。
聚合報告中部分值的計算方法：
-
吞吐量 = 完成的請求數 / 完成這些請求數所需要的時間
-
平均響應時間 = 所有響應時間的總和 / 完成的請求數
-
失敗率 = 失敗的個數 / 總數
-
時間的計算方法是：通過timeStamp時間戳（發出的起始時間）相減而得