概述
我們在用jmeter做性能測試的時候，有一些關鍵性的性能指標需要去分析。但是由於開源工具本身的侷限性，這些指標在工具中的命名極易對我們造成混淆。所以我們需要對這些指標一一進行剖析。
指標分析
響應時間：
假設我們把響應時間分爲如下幾段：
用戶通過客戶端向服務端發出請求的時間爲： T1
服務端接收到請求，處理該請求的時間爲：T2
服務端返回數據給客戶端時間爲： T3
客戶端接收到響應數據，處理數據呈現給用戶時間爲：T4
從系統視角來看：
系統的響應時間Ts= T1+T2+T3。該時間沒有包括客戶端對數據處理並呈現的時間T4
從用戶視角來看：
用戶眼中的的響應時間：Tu = T1+T2+T3+T4。用戶通過客戶端發出業務請求，到客戶端展現相應的請求結果，這個過程的時間越短越好
從服務器視角來看：
服務器接收到客戶端發送的請求，並給出響應，這個過程所消耗的時間爲響應時間，即服務器僅關注T2
從不同的視角下，衡量響應時間的指標也各不相同。在實際測試過程中，要明確以什麼視角驗證被測對象的性能。
大多數情況下，我們用jmeter做性能測試的響應時間都以用戶視角去看待。
吞吐量：
我們用單位時間內系統處理請求的數量來定義它。吞吐量直接體現了軟件系統的業務處理能力
衡量方式如下幾種：
請求數 / 單位時間
點擊數 / 單位時間
字節數 / 單位時間
jmeter在聚合報告中把吞吐量命名爲Throughput
這裏要說兩個概念，TPS和QPS
TPS：Transactions Per Second（每秒處理的事物數）。一個事務是指向服務器發送請求然後服務器做出反應的過程
QPS：每秒查詢率。它是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準
那麼我們對於一個頁面做一次訪問，就會形成一個TPS；但一次頁面訪問，可能產生多次對服務器的請求，服務器對這些請求，計爲“QPS“。
如果訪問一個頁面會請求服務器3次，那麼一次訪問產生一個“T”，產生3個“Q”
我們可以用jmeter做一個實驗，用一個線程組模擬一個用戶去訪問一下騰訊新聞首頁。那麼這一個事物就是一個TPS
觀察聚合報告裏面的Throughput=7.6/s
它表示這一個線程在一秒內向服務器發送了7.6次請求，此時的Throughput可以理解爲QPS。也就是一個TPS產生了7.6個QPS
但是如果我們在這一個請求上掛一個事物控制器，如下所示
此時在聚合報告中，Throughput就不可以和QPS劃等號了，而是等同於TPS，它表示我們的系統每秒鐘能處理3.4個事物
再比如下圖。從登錄到退出中間的一系列流程如果都掛在事物控制器下，那麼它們整體就可以算做一個事物。TPS就表示每秒鐘這一整個流程的處理數量
例：1分鐘內系統可以處理1000次考勤打卡事物，則吞吐量TPS=1000/60=16.7 (次/秒)
如下圖，則表示系統每秒鐘能處理7次請求
併發數（線程數）：
廣義
單位時間內同時發送給服務器的請求數，不限定具體業務類型，強調的是同時發送
狹義
是單位時間內同時發送給服務器的相同的業務請求數，需限定具體的業務類型，強調業務請求相同
服務端視角
併發數爲單位時間內服務端接收到的請求數
客戶端視角
客戶端的某個具體業務行爲包括多個請求，併發數可被理解爲客戶端單位時間內同時發送給服務器端的請求數
用戶視角
客戶端的業務請求一般爲用戶操作行爲，併發數也可理解爲併發用戶數，又可稱爲虛擬用戶數
未完待續。。。。。。
