jmeter(四十四)經常使用性能指標分析

概述

咱們在用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次請求

併發數（線程數）：

廣義

單位時間內同時發送給服務器的請求數，不限定具體業務類型，強調的是同時發送

狹義

是單位時間內同時發送給服務器的相同的業務請求數，需限定具體的業務類型，強調業務請求相同

服務端視角

併發數爲單位時間內服務端接收到的請求數

客戶端視角

客戶端的某個具體業務行爲包括多個請求，併發數可被理解爲客戶端單位時間內同時發送給服務器端的請求數

用戶視角

客戶端的業務請求通常爲用戶操做行爲，併發數也可理解爲併發用戶數，又可稱爲虛擬用戶數

未完待續。。。。。。