jmeter壓力測試中的疑難雜症

概述

大部分新手在用jmeter作壓力測試的時候，對一些性能術語十分模糊，直接致使的後果就是對測試出來的結果數據根本不能理解，更談不上分析了。今天的文章就着重給你們解釋一下壓力測試中的一些專有名詞

 

問題1：什麼是壓力測試

問到如何作壓力測試，不少人可能只會回答："加線程組，加併發，看結果"。那麼什麼是壓力，壓力從哪裏體現？這些恐怕就不得而知了。。。

到底什麼是壓力呢？實際上咱們在壓力測試中用RPS來表示

是否是有點懵了？什麼是RPS呢？

RPS 就是每秒請求數（Request Per Second），它描述了施壓引擎向服務器實際發出的壓力大小。

Rps 由併發數和服務器響應時間決定。併發數太低時可能達不到預期的 RPS，併發數太高時可能壓力過大直接就壓垮了服務器。

 

問題2：jmeter怎麼調節壓力

從前面的描述中咱們已經知道壓力就是每秒發出的請求數。如今再來理解一個名詞Ramp-up-period（in seconds）

jmeter在線程組中有一個可調節的數值：Ramp-up-period，它表示啓動全部線程須要的時間，單位是秒

以下圖，我設置了100個線程，迭代次數=1，Ramp-up-period=25，那麼它表示我將在25秒內啓動100個線程，也就是每秒鐘啓動4個線程。

每一個線程啓動之間的間隔時間是25/100=0.25s,也就是250ms。

換個理解方式，它表示了咱們預期給服務器的壓力就是每秒鐘發送4個請求。也就是說，設置的RPS=4/s

以下圖，如今是否是能理解一些了？

 

 jmeter中的RPS是沒法經過監聽器來直觀的監測到，可是能夠經過側面方式去驗證一下。

下圖右上角能清晰的看出，咱們100個線程用了25s才徹底加載，或者說咱們用了25s才成功的把100個請求發出去。那麼每秒的請求就是4

 

由於咱們的腳本是單接口，因此理論上來講，此時的TPS=HPS=RPS.下圖能夠看出咱們的幾個指標都是4/s。

HPS

 

TPS

 

 

 

問題3：jmeter中的throughput究竟是什麼？

各位小夥伴們在使用jmeter時，是否是經常被 throughput 搞暈？處處都是throughput ，究竟是作什麼用的呢？

 

咱們先來看看有哪些throughput 元件

定時器中有目標Constant Throughput 和 Throughput Shaping Timer

 

 

邏輯控制器中有吞吐量控制器

 

 聚合報告中也有一個Throughput

撐不住了，好暈啊。。。啊。。。啊。。。。

穩住不要暈倒，下面帶你們一個個的來梳理，重建jmeter世界觀

 

先來理解一下什麼是Throughput

Throughput是用來衡量吞吐量的指標，一般由TPS和QPS來表示。

TPS表示每秒經過的事物數，QPS表示每秒查詢接口數。

jmeter中若是隻有單接口，那麼TPS=QPS。

若是是多接口的混合場景，只有在事物控制器下執行，才能將其理解爲TPS。

 

聚合報告中的 Throughput

下圖Throughput表示無限迭代下的業務吞吐量TPS，大約是99/s。意思就是每秒能處理99筆事物。

或者能夠理解爲：每秒能處理完成的請求數是99

 

Constant Throughput Timer

如今咱們在接口下添加一個 Constant Throughput Timer

這是一個吞吐量定時器，它能夠控制咱們的TPS。

如圖，我設定了目標吞吐量是240/min,也就是4/s。

 

接下來運行的結果能夠看到，不管咱們預期的吞吐量有多大，實際的TPS都被強力壓縮在4/s，同時咱們的平均響應時間也變的很短

 

 

Throughput Shaping Timer

再來看一下 Throughput Shaping Timer

下圖能夠很明顯看到它是用來控制RPS的，也就是每秒請求數。

start=1 end=100，持續時間是60。表示咱們須要在60s內將RPS（每秒請求數）均勻的從1提高到100。

 

 

下面能夠看出來咱們的每秒請求數均勻的在提高

 

邏輯控制器-吞吐量控制器

這個控制器裏的吞吐量，指的是請求比例。

好比咱們總共發出9000個請求，這個控制器下的接口只會發送3000個，比例控制在30%

下面這張圖更直觀的說明了請求的比例分配

login1的控制器分配的比例是30%，剩餘的70%都分給了login2的控制器