『動善時』JMeter基礎 — 60、固定吞吐量測試
- 2021 年 12 月 30 日
- 筆記
- 測試基礎技能 - JMeter工具
1、定時器介紹
默認情況下，JMeter執行緒發送請求之間是沒有間歇的。建議為執行緒組添加某種定時器，以便設定請求之間的間隔是多長時間。如果測試人員不設定這種延遲，JMeter可能會在短時間內產生大量的並發訪問請求，導致伺服器宕機。
定時器會讓作用域內的每一個取樣器，都在執行前等待一個固定時長。定時器可以作為取樣器或者邏輯控制器的子項，目的是隻影響作用域內的取樣器。
如果測試人員為執行緒組添加了多個定時器，那麼JMeter會將這些定時器的時長疊加起來，共同影響作用域範圍內的取樣器。
2、固定吞吐量定時器介紹
一般我們進行壓力測試時，會通過測試獲取QPS（TPS）值，來判斷系統的性能。
但有時為了復現線上生產的問題，需要儘可能還原生產場景，這時就可以通過設置固定的QPS（TPS）值，復現和線上生產過程相同的壓測。
那麼如何實現此要求呢？
可通過固定吞吐量定時器（Constant Throughput Timer）組件來實現。
該定時器引入了變數暫停，通過計算使得總吞吐量（以每分鐘去計算）儘可能接近給定的數字。當然，如果伺服器不能處理它，或者如果有其他定時器或耗時的測試原件阻止它，那麼吞吐量將更低。
雖然該計時器被稱為常數吞吐量定時器，但吞吐量值並不一定是常數。它可以根據變數或函數調用定義，並且可以在測試期間改變該值。
通過以下多種方式都可以改變：
- 使用計數器變數。
- 使用一個
__jexl3或者__groovy函數，來提供一個變化的值。 - 使用遠程BeeShell腳本更改JMeter屬性。
3、固定吞吐量定時器介面說明
添加固定吞吐量定時器組件操作：選中「取樣器」右鍵 —> 添加 —> 定時器 —> 固定吞吐量定時器。
介面如下圖所示：
下面是固定吞吐量定時器組件的詳細說明：
- 名稱：固定吞吐量定時器組件的自定義名稱，見名知意最好。
- 注釋：即添加一些備註資訊，對該固定吞吐量定時器組件的簡短說明，以便後期回顧時查看。
Delay before each affected sampler：設置每個受影響取樣器的延遲。
Target throughput (in samples per minute)：設置每分鐘的目標吞吐量（以每分鐘樣本為單位）
注意這裡的時間是分鐘，不是per second（秒），
即：測試在20 QPS情況下的系統表現，那麼這裡我們應該填 20*60=1200。Calculate Throughput based on：以下面哪個選項為基礎，來計算吞吐量。this thread only：控制每個執行緒的吞吐量。
選擇這種模式時，總的吞吐量=Target throughput* 該執行緒的數量。all active threads：設置的Target throughput將分配到所有執行緒組的所有活動執行緒上，每個活躍執行緒在上一次運行結束後，等待合理的時間後再次運行。（活躍執行緒指同一時刻同時運行的執行緒）
在這種情況下，每個執行緒組需要一個具有相同設置的固定吞吐量定時器。all active threads in current thread group：設置的Target throughput將分配在當前執行緒組的每一個活躍執行緒上，每個執行緒將根據上次運行時間延遲。當測試計劃中只有一個執行緒組時，該選項和all active threads選項的效果完全相同。all active threads (shared)：與all active threads的選項基本相同。唯一區別是，每個活躍執行緒都會在所有活躍執行緒上一次運行結束後，等待合理的時間後再次運行（延遲）。相當於讓所有執行緒組整體排隊。all active threads in current thread group (shared)：與all active threads in current thread group基本相同，唯一的區別是，每個活躍執行緒都會在所有活躍執行緒的上一次運行結束後，等待合理的時間後再次運行（延遲）。 相當於執行緒組組內排隊。
4、固定吞吐量定時器的使用
需求說明：模擬一個用戶組以20QPS的頻率來訪問伺服器，持續10秒鐘，查看伺服器平均響應時間。
（1）測試計劃內包含的元件
添加元件操作步驟：
- 創建測試計劃。
- 創建執行緒組：
選中「測試計劃」右鍵 —> 添加 —> 執行緒（用戶） —> 執行緒組。 - 在執行緒組下，添加取樣器「HTTP請求」組件：
選中「執行緒組」右鍵 —> 添加 —> 取樣器 —> HTTP請求。 - 在取樣器下，添加定時器「固定吞吐量定時器」組件：
選中「取樣器」右鍵 —> 添加 —> 定時器 —> 固定吞吐量定時器。 - 在執行緒組下，添加監聽器「聚合報告」組件：
選中「執行緒組」右鍵 —> 添加 —> 監聽器 —> 聚合報告。
最終測試計劃中的元件如下：
點擊運行按鈕，會提示你先保存該腳本，腳本保存完成後會直接自動運行該腳本。
（2）登陸請求內容
標準的POST請求，添加請求的基本要素，和所需要的數據即可。
如下圖所示：
（3）固定吞吐量定時器內容
固定吞吐量定時器配置內容：
- 設置每分鐘的目標吞吐量：因為我們是模擬20QPS情況下的系統表現，那麼這裡我們應該填 20*60=1200。
提示：60表示一分鐘有60秒。 - 選擇哪些執行緒組，來計算吞吐量：就選擇
this thread only就可以。
編輯完成的內容如下：
（4）執行緒組元件內容
前面只是配置了單位時間的目標吞吐量，下面我們要接著配置JMeter持續發送請求的時間。
在執行緒組元件中的配置如下：
- 在執行緒屬性的循環次數，勾選上「永遠」，（此時旁邊的
editText就無法輸入了）。 - 勾選「調度器」，在持續時間中配置10秒，或在啟動時間、結束時間處配置一個時間間隔為10秒的時間區間。
如下圖所示：
提示：
當然我們也可以進行估算，來設置循環次數。
設置循環次數= 訪問頻率（QPS） * 持續時間，即：20 * 10 = 200。
（5）查看聚合報告的結果
運行腳本，結果如下：
我們可以從上圖中看到，Throughput的值為20QPS，證明測試復現了線上的壓力環境，然後去查看其他的監聽數據是否有異常。（每次Throughput的值會有稍微的浮動）
聚合報告參數介紹：
Label：請求的名稱，就是腳本中Sampler的名稱。# Samples（樣本）：總共發給伺服器的請求數量，如果模擬10個用戶，每個用戶迭代10次，那麼總的請求數為：10*10 =100次。Average（平均值）：默認情況下是單個Request的平均響應時間，當使用了Transaction Controller（事務控制器） 時，也可以用Transaction的時間，來顯示平均響應時間 ，單位是毫秒。Median（中位數）：50%用戶的響應時間小於該值。90% Line（90% 百分位）：90%用戶的響應時間小於該值。95% Line（95% 百分位）：95%用戶的響應時間小於該值。99% Line（99% 百分位）：99%用戶的響應時間小於該值。Min（最小值）：最小的響應時間。Maximum（最大值）：最大的響應時間。Error%（異常%）：錯誤率=錯誤請求的數量/請求的總數。Throughput（吞吐量）：默認情況下表示每秒完成的請求數（Request per Second）。Received KB/sec（接收數據）：每秒從伺服器端接收到的數據量。Sent KB/sec（發送）：每秒發送到伺服器端的數據量。
參考：
