硬核！如何模拟 5w+ 的并發使用者？

本文将從負載測試的角度，描述了做一次流暢的5萬使用者并發測試需要做的事情。

你可以在本文的結尾部分看到讨論的記錄.

快速的步驟概要

編寫你的腳本

使用JMeter進行本地測試

BlazeMeter沙箱測試

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

設定并測試你的集合 (1個控制台和10-14 引擎)

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

步驟1 : 編寫你的腳本

開始之前，請确定從JMeter的Apache社群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.

将該測試按照最終測試的全部時長運作。當測試在運作時，打開監聽标簽，并且檢驗：

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

2，定位你的控制台标簽（你可以通過一次點選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頁中找到生成的聚合結果的報告，你還可以通過打開單個的報告來獨立的檢視每一個測試結果。

原文：

http://blazemeter.com/blog/how-run-load-test-50k-concurrent-users

譯文：

http://t.cn/ES7KBkW