jmeter終極線程組中如何控制頻率

Question

我在 JMeter 中使用 Ultimate Thread Group 作為一個簡單的腳本，其中包括一些模擬登錄流程的請求。

測試將在非 GUI 模式下運行。 腳本如下所示：

1. 思考時間 - 動態值 [3-5] 秒
2. 登錄
3. 思考時間 - 動態值 [3-5] 秒
4. 獲取令牌
5. 思考時間 - 動態值 [3-5] 分鍾（模擬用戶會話）
6. 登出

Ultimate Thread Group 中的線程總數將為 250。初始延遲=0 啟動時間=250 保持負載=400 秒關閉時間=250

我有關於 Ultimate Thread Group 和客戶端頻率的問題

終極線程組

1. 我可以假設 Jmeter 每秒會增加 1 個用戶，直到我們有 250 個用戶？
2. 然后考慮到動態思考時間，我可以期望服務器吞吐量達到服務器可以回復的最大值嗎？
3. 我們每秒將有大約 250 個來自客戶端的並發請求，就像來自客戶端的吞吐量一樣？ 恐怕我可以向服務器發送太多垃圾郵件..

客戶端吞吐量

例如，如果我需要從客戶端控制吞吐量，我可以使用恆定吞吐量計時器 (CTT) 嗎？ 例如，我有一個要求 - 登錄流 250 個並發用戶，服務器吞吐量應該能夠處理 ~ 每秒 5 個請求。

因此，在使用 CTT 的情況下，我是否應該從腳本中刪除所有思考時間（除了 1 - 2-3 分鍾來模擬用戶會話）並只在腳本末尾放置一個 CTT？

我的最終設置將是：

Ultimate Thread Group 中的線程總數將為 250。初始延遲=0 啟動時間=250 保持負載=400 秒關閉時間=250

如何配置 CTT 以每秒從客戶端加載 2 個請求並考慮 250 個並發用戶？

Answer 1

使用您的設置

1. 是的，Ultimate 線程組每秒會增加 1 個用戶，直到獲得 250 個用戶。
2. 不，由於您使用的是思考時間（希望它是統一隨機計時器），因此您不會從 JMeter 到您的服務器獲得最大可能的命中
3. 不，如前所述，由於您的思考時間在 3 到 5 秒之間，因此您不會體驗到 250 的 RPS。但是如果您刪除思考時間而不添加計時器來控制吞吐量，則可以獲得更高的吞吐量（有時甚至超過 250 )

正如您所計划的，您可以使用恆定吞吐量計時器（在這種情況下，您可以刪除思考時間）。 但是對於這種情況，如果您有每秒 2 個請求的請求，我建議您使用jp@gc - 吞吐量整形計時器。 因為出於某種原因，它似乎與最終線程組一起工作得更好。

只是給你一些輸入，我在 JMeter 中創建了一個類似的場景，請查看下面的圖片

在這個樣本中

啟動線程：25，初始延遲：0，啟動時間：25，保持負載：10，關閉時間：25

在執行過程中，如果您檢查jp@gc - Active Threads Over Time圖表，它將如下所示

當您添加思考時間時，這是您的 RPS（吞吐量）

如果您刪除思考時間並且如果您沒有計時器來控制吞吐量，這就是您的 RPS（如您所見，即使我有 25 個線程，RPS 也可以 go 傳遞 25 ）

但是，當您刪除思考時間並添加一個計時器（我已添加計時器以使開始和結束 RPS 為 2 為 60 秒）來控制吞吐量時，將如下所示。 如您所見，在任何給定時間，吞吐量都不會超過 2。

如果您添加兩個計時器（60 年代的 RPS 2）並認為 RPS 的時間看起來像這樣。 在此圖中，您將看到 RPS 大於 2 的某些情況。這是由於思考時間造成的。 （如果前一個請求的思考時間為 5 秒，而新的兩個請求的思考時間為 3 秒）這可能會發生。 但它不會損害測試。

所以在你的計划中，你添加

• Ultimate Thread Group 中的線程總數將為 250。初始延遲=0 啟動時間=250 保持負載=400 秒關閉時間=250
• 吞吐量整形定時器或 CTT 來控制預期的吞吐量
• 留出思考時間來創造更現實的行為（可選）

注意：您始終可以使用虛擬采樣器並嘗試檢查您是否達到了計划的預期結果。

希望這可以幫助。 干杯