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（發送）：每秒發送到服務器端的數據量。
參考：