并發通常用于定義負載測試的工作負載，例如并發用戶。通常，它是唯一定義的輸入。實際上，有許多因素會增加工作量并影響并發性。動力節點小編將在本文中探討其中的一些。

如何計算目標并發用戶

一種常見的方法是將唯一用戶數除以給定時間段的平均訪問持續時間。

例如，每小時 12,000 個唯一身份訪問者/(每次訪問 60 分鐘/15 分鐘)將等于 3,000 個并發用戶。

這種方法的問題包括：

假設訪問者均勻分布在采樣的 1 小時內。訪問者更有可能遵循某種形式的泊松過程。

唯一身份訪問者的數量可能計算錯誤。根據用于對唯一性進行抽樣的方法，這通常會產生誤導，尤其是在使用源 IP 之類的東西時，這些東西通常可以由真實用戶共享或代理。

并發有助于但不定義整體工作負載。這些用戶實際上在做什么?空閑還是忙碌?更多的計算方法可能是分析或跟蹤不同時期的真實用戶，或者使用除上述平均值之外的描述性統計數據來顯示頻率分布或箱線圖，以便您可以更好地模擬并發使用。

獲得正確的并發性很重要，因為最終，工作負載很可能由某種形式的排隊系統處理，并且并發性會影響這些隊列的到達時間。

在現實生活中的計算機系統中，分布很少是均勻的，因此最好在被測系統中嘗試觀察、理解和建模并發性。

如何啟動并發用戶

假設您已經創建了一個模型(好或壞)，現在是時候使用您最喜歡的負載測試工具并在負載下模擬該模型了。

JMeter 的核心是一個JMeter線程組，它允許您定義有多少用戶、一個加速期以及執行測試的次數或測試的固定持續時間。從本質上講，加速會延遲單個線程的啟動。

例如，3,000 名并發用戶的啟動時間為 300 秒，將在每個用戶啟動之間施加 10 秒的延遲。

這為啟動線程提供了線性、均勻的分布，因此除非您的目標是在所有用戶啟動后測量性能(并忽略啟動本身)，否則此方法不太可能模擬真實的負載配置文件。

流行的JMeter 插件庫提供了一個名為 Ultimate Thread Group 的替代方案，顧名思義，它為您提供了更多啟動并發用戶的選項。這包括可變數量的線程、加速時間和持續時間。通過耐心和一點點RSI將信息插入 UI，您可以創建更真實的并發負載配置文件。

FWIW，我經常在加速階段發現許多與性能相關的缺陷，特別是對于初學者來說更現實的模型。這是您測試中監控和衡量性能的重要時期。很多時候，這段時間會從測試結果中被忽略。

如何運行并發用戶

既然您的用戶已經開始并且測試正在進行中，許多測試人員將專注于這段測試，并將其作為進一步觀察和結果的基礎。一些測試人員可能將其稱為“峰值并發負載”或“穩態負載”。

除了并發性之外，影響這一時期的一個關鍵因素是吞吐量。

吞吐量可以通過許多不同的方式來衡量，例如網絡吞吐量或每秒的請求數。但最終，吞吐量是由用戶在被測系統上執行某些操作來創建的。正如我之前提到的，如果大多數用戶只是空閑，那么高并發用戶測試可能沒有多大意義，因此吞吐量對于建模和有效模擬同樣重要。

吞吐量最常受到思考時間(用戶事務之間)或步調(每次迭代之間的時間)等因素的影響，但它也受到任何系統隊列中的服務時間的影響，例如 Web 應用程序響應時間或網絡延遲和帶寬。

泊松過程或每對連續事件之間的時間具有指數分布，并且這些到達間隔時間中的每一個都被假定為獨立于其他到達間隔時間。

那么我們如何模擬呢?

JMeter 有一套不錯的計時器，可用于幫助隨機化用戶操作的到達間隔時間。我喜歡使用Gaussian Random Timer將每個請求隨機延遲在一個恒定的延遲偏移附近(根據高斯曲線分布)。

JMeter 還有一個Test Action控制器，我喜歡用它在每次迭代結束時添加一個變量 pause 。這可以幫助確定節奏，或每個用戶通過交易列表的速率。盡管如此，迭代之間的節奏可能很難正確，尤其是如果您的目標是模擬平均訪問持續時間，例如。

我認為最好的方法是使用單個用戶和多次迭代手動修改腳本，這樣您就可以了解迭代之間的時間安排。

可以使用吞吐量控制器控制特定代碼塊的執行頻率。我更喜歡使用百分比執行，以便我可以通過測試計劃“加權”一定百分比的迭代。

吞吐量計時器也很有用，因為它引入了可變暫停，計算以保持總吞吐量(以每分鐘樣本數計)盡可能接近給定數字，該數字本身可以是隨機的。

將每分鐘的樣本(當 JMeter 執行它們時)轉換為模型的吞吐量目標可能很困難。

需要一定的努力/理解才能準確地建模。

了解結果!

假設您已經獨立地擺脫了 JMeter 腳本，您還可以使用免費節點在 Flood IO 上運行它們以了解可用報告。

Flood IO中的并發是測試計劃中所有線程組的活動線程數。但是，在您對使用 JMeter 或任何其他流行的負載測試工具生成的大量并發數感到興奮之前，必須考慮一下測試計劃中并發的實際含義。

可能有 100K 用戶處于完全空閑狀態，或者 1K 用戶的迭代速度比一千只受驚的瞪羚還快，從而有效地將相同的工作負載應用到被測系統上。因此，作為單一度量的并發性缺乏上下文。

您應該查看的其他重要指標包括吞吐量和錯誤。有幾種方法可以查看吞吐量、網絡或請求，我通常更喜歡后者，因為它與外部監控工具很好地結合在一起。

從客戶端監視錯誤對于幫助跟蹤服務器端的潛在瓶頸非常重要。例如，響應代碼圖將幫助您顯示非 HTTP 200 響應代碼。您還可以在事務響應時間圖中查看失敗的事務計數。

結論

并發本身不足以定義系統工作負載。可以結合使用其他指標(例如吞吐量)來幫助描述工作負載。

當心平均值和均勻分布。大多數商業和開源測試工具中的默認設置通常不足以模擬真實的工作負載模型。

在您的測試計劃中啟動或增加用戶與“穩態”負載一樣重要。不要丟棄結果!

始終尋找不同指標之間的關系，例如并發、吞吐量和響應時間。永遠不要忽視錯誤!

以上就是關于“JMeter高并發負載測試”的介紹，大家如果想了解更多相關知識，不妨來關注一下動力節點的JMeter教程，里面的課程內容更加詳細，由淺到深，適合沒有基礎的小伙伴學習，希望對大家能夠有所幫助。