厲害了！JMeter 模擬超過 5 萬的并發(fā)用戶！
來源：oschina.net/translate/how-run-load-test-50k-concurrent-users
本文將從負載測試的角度，描述了做一次流暢的5萬用戶并發(fā)測試需要做的事情。
你可以在本文的結尾部分看到討論的記錄。
快速的步驟概要
# 編寫你的腳本
開始之前，請確定從JMeter的Apache社區(qū)jmeter.apache.org 獲得了最新的版本。
你也會要下載這些附加的插件 ，因為它們可以讓你的工作更輕松。
有許多方法可以獲得腳本:
使用 BlazeMeter 的 Chrome 擴展 來記錄你的方案
使用 JMeter HTTP(S) 測試腳本記錄器 來設置一個代理，那樣你就可以運行你的測試并記錄下所有的東西
從頭開始全部手工構建(可能是功能/QA測試)
如果你的腳本是一份記錄的結果(像步驟1&2), 請牢記:
你需要改變諸如Username & Password這樣的特定參數(shù)，或者你也許會想要設置一個CSV文件，有了里面的值每個用戶就可以是不同的.
為了完成諸如“添加到購物車”，“登錄”還有其它這樣的請求，你也許要使用正則表達式，JSON路徑提取器，XPath提取器，來提取諸如Token字符串，表單構建ID還有其它要素
保持你的腳本參數(shù)化，并使用配置元素，諸如默認HTTP請求，來使得在環(huán)境之間切換時你的工作更輕松.
# 使用JMeter進行本地測試
在1個線程的1個迭代中使用查看結果樹要素，調試樣本，虛擬樣本還有打開的日志查看器（一些JMeter的錯誤會在里面報告），來調試你的腳本。
遍歷所有的場景(包括True 或者 False的回應) 來確保腳本行為確如預期……
在成功使用一個線程測試之后——將其提高到10分鐘10到20個線程繼續(xù)測試:
如果你想要每個用戶獨立——是那樣的么?
有沒有收到錯誤?
如果你在做一個注冊過程，那就看看你的后臺 - 賬戶是不是照你的模板創(chuàng)建好了? 它們是不是獨立的呢?
從總結報告中，你可以看到對測試的統(tǒng)計 - 它們有點用么? (平均響應時間, 錯誤, 每秒命中率)
一旦你準備好了腳本:
通過移除任何調試和虛擬樣本來清理腳本，并刪除你的腳本偵聽器。
如果你使用了偵聽器(諸如 "將響應保存到一個文件")，請確保你沒有使用任何路徑! , 而如果他是一個偵聽器或者一個CSV數(shù)據(jù)集配置——請確保你沒有使用你在本地使用的路徑 - 而只要文件名(就好像跟你的腳本在同一個文件夾)
如果你使用了自己專有的JAR文件，請確保它也被上傳了。
如果你使用了超過一個線程組（不是默認的那個) - 請確保在將其上傳到BlazeMeter之前設置了這個值。
# BlazeMeter沙箱測試
如果那時你的第一個測試——你應該溫習一下 這篇 有關如何在BlazeMeter中創(chuàng)建測試的文章。
將沙箱的測試配置設置成，用戶300，1個控制臺, 時間50分鐘。
對沙箱進行這樣的配置讓你可以在后臺測試你的腳本，并確保上的BlazeMeter的一切都運行完好。
為此，先按下灰色的按鈕: 告訴JMeter引擎我想要完全控制! - 來獲得對你的測試參數(shù)的完全控制。
通常你將會遇到的問題:
防火墻 - 確保你的環(huán)境對BlazeMeter的CIDR 列表 (它們會實時更新)開發(fā)，并把它們放入白名單中
確保你所有的測試文件, 比如: CSVs, JAR, JSON, User.properties 等等.. 都可以使用
確保你沒有使用任何路徑
如果仍然有問題，那就看看錯誤日志吧(你應該可以把整個日志都下載下來)。
一個沙箱的配置可以是這樣的:
引擎: 是能使控制臺(1 個控制臺 , 0 個引擎)
線程: 50-300
產能提升: 20 分鐘
迭代: 一直測試下去
時間: 30-50 分鐘
這可以讓你在產能提升期間獲得足夠多的數(shù)據(jù)(以防你遇到問題) ，而你將可以對結果進行分析，以確保腳本的執(zhí)行確如預期。
你應該觀察下Waterfall / WebDriver 選項卡來看看請求是否正常，你不應該在這一點上出任何問題（除非你是故意的)。
# 使用1個控制臺和1個引擎來設置每個引擎用戶的數(shù)量
現(xiàn)在我們可以肯定腳本能在BlazeMeter中完美運行了——我們需要計算出要多少用戶放到一個引擎中。
如果你能用戶沙箱中的數(shù)據(jù)來做這個決定，那就太棒了!
在這里，我會給出一種不用回頭去查看沙箱測試數(shù)據(jù)就能計算出這個數(shù)的方法。
設置你的測試配置:
線程數(shù): 500
產能提升：40 分鐘
迭代: 永久
時長: 50 分鐘
使用一個控制臺和一個引擎。
運行測試并(通過監(jiān)視選項卡)對你的測試引擎進行監(jiān)視。
如果你的引擎對于75%的CPI使用率和85%的內存使用率都沒有達到(一次性的峰值可以忽略) 的話:
將線程數(shù)調整到700在測試一次
提交線程的數(shù)量直到線程數(shù)達到1000或者60%的CPU或內存使用
如果你的引擎過了75%的CPU使用率或者85%的內存使用率(一次性的峰值可以忽略 :
看看你第一次達到75%的點，在那個點有多少并發(fā)用戶.
在運行一次測試, 而不是提高你之前500個用戶數(shù)量的產能
這一次將產能提升放到真實的測試中(5-15 分鐘是一個好的開始) 并將時長設置為50分鐘.
確保整個測試過程中沒有超過75%的CPU使用率或者85%的內存使用率…
為安全起見，你可以把每個引擎的線程數(shù)降低10%的。
# 安裝并測試集群
我們現(xiàn)在知道了從一個引擎中我們得到了多少線程，在該章節(jié)的最后，我們將會知道一個集群能給我們提供多少用戶。
一個集群是指具有一個控制臺（僅有一個）和0-14個引擎的邏輯容器。
即使你可以創(chuàng)建一個使用超過14個引擎的測試案例——但實際上是創(chuàng)建了兩個集群（你可以注意到控制臺的數(shù)量增加了），并且克隆了你的測試案例……
每個集群具有最多14個引擎，是基于BlazeMeter自己本身的測試，以確?？刂婆_可以控制這14臺引擎對新建的大量數(shù)據(jù)處理的壓力。
所以在這一步驟中，我們會用步驟4種的測試，并且僅僅修改引擎數(shù)量，將其增加到14。
將該測試按照最終測試的全部時長運行。當測試在運行時，打開監(jiān)聽標簽，并且檢驗：
沒有一個引擎超過CPU75%的占有率和內存85%占有率的上限；
定位你的控制臺標簽（你可以通過一次點擊Logs Tab->Network Information，查看控制臺私有IP地址來找到它的名字）——它不應該達到CPU75%占有率和內存85%占有率的上限。
如果你的控制臺達到了該上限——減少引擎數(shù)量并重新運行直到控制臺在該上限之下。
在這個步驟的最后，你會發(fā)現(xiàn)：
每個集群的用戶數(shù)量；
每個集群的命中率。
查看Aggretate Table中的其他統(tǒng)計信息，并找到本地結果統(tǒng)計圖來獲得有關你集群吞吐量的更多信息。
# 使用 Master / Slave 特性來達成你的最大CC目標
我們到了最后一步了。
我們知道腳本正在運行，我們也知道一個引擎可以支持多少用戶以及一個集群可以支持多少用戶。
讓我們做一下假設：
一個引擎支持500用戶
一個集群可以用戶12個引擎
我們的目標是5萬用戶測試
因此為了完成這些，我們需要8.3 個集群
我們可以用8個12臺引擎的集群和一個4太引擎的集群 - 但是像下面這樣分散負載應該會更好：
每個集群我們用10臺引擎而不是12，那么每個集群可以支持 10*500 = 5K 用戶并且我們需要10個集群來支持5萬用戶。
這樣可以得到如下好處：
不用維護兩個不同的測試類型
我們可以通過簡單的復制現(xiàn)有集群來增加5K用戶（5K比6K更常見）
只要需要我們可以一直增加
現(xiàn)在，我們已經準備好創(chuàng)建最終的5萬用戶級別的Master / Slave測試了：
你的5萬用戶級別的Master-Slave測試已經準備好了。通過按master上的開始按鈕來運行10個測試，每個測試5千用戶。
你可以修改任意一個測試（salve或master），讓它們來自不同的區(qū)域，有不同的腳本/csv/以及其他文件，使用不同的網絡模擬器，不同的參數(shù)等。
最后，關注公眾號互聯(lián)網架構師，在后臺回復：2T，可以獲取我整理和創(chuàng)作的 Java 系列教程非常齊全。
1、2019 年 9 月全國程序員工資統(tǒng)計，你是什么水平？
5、37歲程序員被裁，120天沒找到工作，無奈去小公司，結果懵了...