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（傳送）：每秒傳送到伺服器端的資料量。
參考：