閱讀本文大概需要 7 分鐘。

英文原文：How to run a load test of 50k+ concurrent users

參與翻譯： LeoXu， 麥殼原野

前言

步驟1 ： 編寫你的指令碼

步驟2 ： 使用JMeter進行本地測試

步驟3 ： BlazeMeter沙箱測試

步驟4 ： 使用1個控制檯和1個引擎來設定每個引擎使用者的數量

步驟5：安裝並測試叢集

步驟 6 ： 使用 Master / Slave 特性來達成你的最大CC目標

本文將從負載測試的角度，描述了做一次流暢的5萬用戶併發測試需要做的事情。你可以在本文的結尾部分看到討論的記錄。快速的步驟概要

編寫你的指令碼

使用JMeter進行本地測試

BlazeMeter沙箱測試

使用一個控制檯和一個引擎設定Users-per-Engine的數量

設定並測試你的集合 （1個控制檯和10-14 引擎）

使用 Master / Slave 特性來達成你的最大CC目標

步驟1 ： 編寫你的指令碼

開始之前，請確定從JMeter的Apache社群

http：//

jmeter。apache。org

獲得了最新的版本。你也會要下載這些附加的外掛 ，因為它們可以讓你的工作更輕鬆。有許多方法可以獲得指令碼：

使用 BlazeMeter 的 Chrome 擴充套件 來記錄你的方案

使用 JMeter HTTP（S） 測試指令碼記錄器 來設定一個代理，那樣你就可以執行你的測試並記錄下所有的東西

從頭開始全部手工構建（可能是功能/QA測試）

如果你的指令碼是一份記錄的結果（像步驟1&2）， 請牢記：

你需要改變諸如Username & Password這樣的特定引數，或者你也許會想要設定一個CSV檔案，有了裡面的值每個使用者就可以是不同的。

為了完成諸如“新增到購物車”，“登入”還有其它這樣的請求，你也許要使用正則表示式，JSON路徑提取器，XPath提取器，來提取諸如Token字串，表單構建ID還有其它要素

保持你的指令碼引數化，並使用配置元素，諸如預設HTTP請求，來使得在環境之間切換時你的工作更輕鬆。

步驟2 ： 使用JMeter進行本地測試

在1個執行緒的1個迭代中使用檢視結果樹要素，除錯樣本，虛擬樣本還有開啟的日誌檢視器（一些JMeter的錯誤會在裡面報告），來除錯你的指令碼。遍歷所有的場景（包括True 或者 False的迴應） 來確保指令碼行為確如預期…在成功使用一個執行緒測試之後——將其提高到10分鐘10到20個執行緒繼續測試：

如果你想要每個使用者獨立——是那樣的麼？

有沒有收到錯誤？

如果你在做一個註冊過程，那就看看你的後臺 - 賬戶是不是照你的模板建立好了？ 它們是不是獨立的呢？

從總結報告中，你可以看到對測試的統計 - 它們有點用麼？ （平均響應時間， 錯誤， 每秒命中率）

一旦你準備好了指令碼：

透過移除任何除錯和虛擬樣本來清理指令碼，並刪除你的指令碼偵聽器

如果你使用了偵聽器（諸如 “將響應儲存到一個檔案”），請確保你沒有使用任何路徑！ ， 而如果他是一個偵聽器或者一個CSV資料集配置——請確保你沒有使用你在本地使用的路徑 - 而只要檔名（就好像跟你的指令碼在同一個資料夾）

如果你使用了自己專有的JAR檔案，請確保它也被上傳了。

如果你使用了超過一個執行緒組（不是預設的那個） - 請確保在將其上傳到BlazeMeter之前設定了這個值。

步驟3 ： BlazeMeter沙箱測試

如果那時你的第一個測試——你應該溫習一下 這篇 有關如何在BlazeMeter中建立測試的文章。將沙箱的測試配置設定成，使用者300，1個控制檯， 時間50分鐘。對沙箱進行這樣的配置讓你可以在後臺測試你的指令碼，並確保上的BlazeMeter的一切都執行完好

為此，先按下灰色的按鈕： 告訴JMeter引擎我想要完全控制！ - 來獲得對你的測試引數的完全控制通常你將會遇到的問題：

防火牆 - 確保你的環境對BlazeMeter的CIDR 列表 （它們會實時更新）開發，並把它們放入白名單中

確保你所有的測試檔案， 比如： CSVs， JAR， JSON， User。properties 等等。。 都可以使用

確保你沒有使用任何路徑

如果仍然有問題，那就看看錯誤日誌吧（你應該可以把整個日誌都下載下來）。一個沙箱的配置可以是這樣的：

引擎： 是能使控制檯（1 個控制檯 ， 0 個引擎）

執行緒： 50-300

產能提升： 20 分鐘

迭代： 一直測試下去

時間： 30-50 分鐘

這可以讓你在產能提升期間獲得足夠多的資料（以防你遇到問題） ，而你將可以對結果進行分析，以確保指令碼的執行確如預期。你應該觀察下Waterfall / WebDriver 選項卡來看看請求是否正常，你不應該在這一點上出任何問題（除非你是故意的）。你應該盯著監控選項卡，觀察期記憶體和CPU消耗 - 這對你在步驟4中嘗試設定每一個引擎的使用者數量。

步驟4 ： 使用1個控制檯和1個引擎來設定每個引擎使用者的數量

現在我們可以肯定指令碼能在BlazeMeter中完美運行了——我們需要計算出要多少使用者放到一個引擎中。如果你能使用者沙箱中的資料來做這個決定，那就太棒了！在這裡，我會給出一種不用回頭去檢視沙箱測試資料就能計算出這個數的方法。設定你的測試配置：

執行緒數： 500

產能提升：40 分鐘

迭代： 永久

時長： 50 分鐘

使用一個控制檯和一個引擎。執行測試並（透過監視選項卡）對你的測試引擎進行監視。如果你的引擎對於75%的CPI使用率和85%的記憶體使用率都沒有達到（一次性的峰值可以忽略） 的話：

將執行緒數調整到700在測試一次

提交執行緒的數量直到執行緒數達到1000或者60%的CPU或記憶體使用

如果你的引擎過了75%的CPU使用率或者85%的記憶體使用率（一次性的峰值可以忽略 ：

看看你第一次達到75%的點，在那個點有多少併發使用者。

在執行一次測試， 而不是提高你之前500個使用者數量的產能

這一次將產能提升放到真實的測試中（5-15 分鐘是一個好的開始） 並將時長設定為50分鐘。

確保整個測試過程中沒有超過75%的CPU使用率或者85%的記憶體使用率…

為安全起見，你可以把每個引擎的執行緒數降低10%的。

步驟5：安裝並測試叢集

我們現在知道了從一個引擎中我們得到了多少執行緒，在該章節的最後，我們將會知道一個叢集能給我們提供多少使用者。一個叢集是指具有一個控制檯（僅有一個）和0-14個引擎的邏輯容器。即使你可以建立一個使用超過14個引擎的測試案例——但實際上是建立了兩個叢集（你可以注意到控制檯的數量增加了），並且克隆了你的測試案例……

每個叢集具有最多14個引擎，是基於BlazeMeter自己本身的測試，以確保控制檯可以控制這14臺引擎對新建的大量資料處理的壓力。所以在這一步驟中，我們會用步驟4種的測試，並且僅僅修改引擎數量，將其增加到14。將該測試按照最終測試的全部時長執行。當測試在執行時，開啟監聽標籤，並且檢驗：

沒有一個引擎超過CPU75%的佔有率和記憶體85%佔有率的上限；

定位你的控制檯標籤（你可以透過一次點選Logs Tab->Network Information，檢視控制檯私有IP地址來找到它的名字）——它不應該達到CPU75%佔有率和記憶體85%佔有率的上限。

如果你的控制檯達到了該上限——減少引擎數量並重新執行直到控制檯在該上限之下。在這個步驟的最後，你會發現：

每個叢集的使用者數量；

每個叢集的命中率。

檢視Aggretate Table中的其他統計資訊，並找到本地結果統計圖來獲得有關你叢集吞吐量的更多資訊。

步驟 6 ： 使用 Master / Slave 特性來達成你的最大CC目標

我們到了最後一步了。我們知道指令碼正在執行，我們也知道一個引擎可以支援多少使用者以及一個叢集可以支援多少使用者。讓我們做一下假設：

一個引擎支援500使用者

一個叢集可以使用者12個引擎

我們的目標是5萬用戶測試

因此為了完成這些，我們需要8。3 個叢集。。我們可以用8個12臺引擎的叢集和一個4太引擎的叢集 - 但是像下面這樣分散負載應該會更好：每個叢集我們用10臺引擎而不是12，那麼每個叢集可以支援 10*500 = 5K 使用者並且我們需要10個叢集來支援5萬用戶。這樣可以得到如下好處：

不用維護兩個不同的測試型別

我們可以透過簡單的複製現有叢集來增加5K使用者（5K比6K更常見）

只要需要我們可以一直增加

現在，我們已經準備好建立最終的5萬用戶級別的Master / Slave測試了：

將測試的名稱從“My prod test” 改為“My prod test - slave 1”。

我們回到步驟5，將高階測試屬性（Advanced Test Properties）下的Standalone修改為Slave。

按儲存按鈕——現在我們有了一個Master和9個Slave中的一個。

返回你的 “My prod test -slave 1”。

按複製按鈕

接下來重複步驟1-5直到你建立了9個slave。

回到你的 “My prod test -salve 9” 並按複製按鈕。

將測試的名稱改為 “My prod test -Master”。

將高階測試屬性（Advanced Test Properties） 下的Slave改為Master。

檢查我們剛才建立的所有的Slave（My prod test -salve 1。。9）並按儲存。

你的5萬用戶級別的Master-Slave測試已經準備好了。透過按master上的開始按鈕來執行10個測試，每個測試5千使用者。

你可以修改任意一個測試（salve或master），讓它們來自不同的區域，有不同的指令碼/csv/以及其他檔案，使用不同的網路模擬器，不同的引數等。

你可以在一個叫“Master load results”的master報告中的一個新tab頁中找到生成的聚合結果的報告，你還可以透過開啟單個的報告來獨立的檢視每一個測試結果。

每天進步一點點

慢一點才能更快

推薦閱讀

：