如何使用jmeter來實現更大批量的併發的解決方案

近期在用JMeter進行負載測試的 時候，發現使用單臺機器模擬測試超過好比500個進程的併發就有些力不從心或者說不能如實的反應實際狀況，在執行的過程當中，JMeter自身會自動關閉， 要解決這個問題，則可使用分佈式測試，運行多臺機器運行所謂的 Agent 來分擔 JMeter自身的壓力（這個和LODARUNNER是同樣的道理），並藉此來獲取更大的併發用戶數,則須要進行相關的配置參數和文件權限進行一些修改， 具體以下：
　　一、在全部指望運行 JMeter 並做爲 Load Generator 的機器上安裝 JMeter，並肯定其中一臺機器做爲 Controller，其餘的機器做爲 Agent——假定咱們使用兩臺機器 192.168.0.1 和 192.168.0.2 做爲 Agent；
　　二、在Controller 機器的 JMeter 安裝目錄下找到 bin 目錄，再找到 JMeter.properties 這個文件，使用記事本或者其餘文字編輯工具打開它；
　 　三、在打開的文件中查找「remote_hosts=」這個字符串，你能夠找到這樣一行「remote_hosts=127.0.0.1」。其 中的 127.0..0.1 表示運行 JMeter Agent 的機器，這裏須要修改成「remote_hosts=192.168.0.1:1099,192.168.0.2:1099」——其中的 1099 爲 JMeter 的 Controller 和 Agent 之間進行通信的默認 RMI 端口號； （我的備註：只改要做爲Controller的機器上的此文件便可；Agent的機器上的文件能夠不理會）
　　四、保存文件，而後依次啓動做爲 Controller的機器上的jmeter-server文件和做爲Agent的機器上的jmeter-server文件（我的備註：若是是 WINDOWS系統版本的jmeter，則是啓動jmeter-server.bat的批處理文件，LINUX系統則是jmeter-server文件， 沒有後綴的，可是要修改成可執行權限，這後面具體有提到），並從新啓動 Controller 機器上的 JMeter.bat，並進入 Run -> Remote Start 菜單項，在這裏能夠看到遠程啓動菜單下面有192.168.0.1 ，192.168.0.1兩個IP地址
　　五、若是要讓某個電腦執行，能夠點擊改電腦的IP地址就能夠，若是兩個都要執行，能夠點擊Run 菜單下的「遠程運行所有」菜單
　 　六、有時候用做代理的機器太少，仍不能知足須要，則須要將做爲Controller的電腦也看成Agent，則一樣須要修改 JMeter.properties文件，將Controller的IP地址寫入。同時，這個時候，須要打先打開Controller 電腦中JMeter下bin目錄下的jmeter-server.bat，而後再打開JMeter.bat，此時，進入Run -> Remote Start菜單，能夠看到Controller也做爲遠程機器進行運行。 （針對第六點我我的通過實地測試後要進行細化確認：若是是在LINUX下，此文件的權限都仍是要修改的，且jmeter-server會調用名爲 jmeter腳本文件，其jmeter文件的權限也要修改成可執行的才能夠，且每一個被調用的Agent的機器的jmeter-server文件也是要執行 中才可用調用，這點很重要。）。

 

如何利用JMeter模擬超過 5 萬的併發用戶

 

http://www.open-open.com/lib/view/open1404264176811.html

閱讀目錄

• 步驟一1 : 編寫你的腳本
• 步驟2 : 使用JMeter進行本地測試
• 步驟3 : BlazeMeter沙箱測試
• 步驟4 : 使用1個控制檯和1個引擎來設置每一個引擎用戶的數量
• 步驟5：安裝並測試集羣
• 步驟 6 : 使用 Master / Slave 特性來達成你的最大CC目標

本文將從負載測試的角度，描述了作一次流暢的5萬用戶併發測試須要作的事情.

你能夠在本文的結尾部分看到討論的記錄.

快速的步驟概要

1. 編寫你的腳本

2. 使用JMeter進行本地測試

3. BlazeMeter沙箱測試

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

5. 設置並測試你的集合 (1個控制檯和10-14 引擎)

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

步驟一1 : 編寫你的腳本

開始以前，請肯定從JMeter的Apache社區jmeter.apache.org 得到了最新的版本.

你也會要下載這些附加的插件 ，由於它們可讓你的工做更輕鬆.

有許多方法能夠得到腳本:

1. 使用 BlazeMeter 的 Chrome 擴展 來記錄你的方案

2. 使用 JMeter HTTP(S) 測試腳本記錄器 來設置一個代理，那樣你就能夠運行你的測試並記錄下全部的東西

3. 從頭開始所有手工構建(多是功能/QA測試)

若是你的腳本是一份記錄的結果(像步驟1&2), 請牢記:

1. 你須要改變諸如Username & Password這樣的特定參數，或者你也許會想要設置一個CSV文件，有了裏面的值每一個用戶就能夠是不一樣的.

2. 爲了完成諸如「添加到購物車」，「登陸」還有其它這樣的請求，你也許要使用正則表達式，JSON路徑提取器，XPath提取器，來提取諸如Token字符串，表單構建ID還有其它要素

3. 保持你的腳本參數化，並使用配置元素，諸如默認HTTP請求，來使得在環境之間切換時你的工做更輕鬆.

回到頂部

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

在1個線程的1個迭代中使用查看結果樹要素，調試樣本，虛擬樣本還有打開的日誌查看器（一些JMeter的錯誤會在裏面報告），來調試你的腳本.

遍歷全部的場景(包括True 或者 False的迴應) 來確保腳本行爲確如預期...

在成功使用一個線程測試以後——將其提升到10分鐘10到20個線程繼續測試:

1. 若是你想要每一個用戶獨立——是那樣的麼?

2. 有沒有收到錯誤?

3. 若是你在作一個註冊過程，那就看看你的後臺 - 帳戶是否是照你的模板建立好了? 它們是否是獨立的呢?

4. 從總結報告中，你能夠看到對測試的統計 - 它們有點用麼? (平均響應時間, 錯誤, 每秒命中率)

一旦你準備好了腳本:

1. 經過移除任何調試和虛擬樣原本清理腳本，並刪除你的腳本偵聽器

2. 若是你使用了偵聽器(諸如 "將響應保存到一個文件")，請確保你沒有使用任何路徑! , 而若是他是一個偵聽器或者一個CSV數據集配置——請確保你沒有使用你在本地使用的路徑 - 而只要文件名(就好像跟你的腳本在同一個文件夾)

3. 若是你使用了本身專有的JAR文件，請確保它也被上傳了.

4. 若是你使用了超過一個線程組（不是默認的那個) - 請確保在將其上傳到BlazeMeter以前設置了這個值.

回到頂部

步驟3 : BlazeMeter沙箱測試

若是那時你的第一個測試——你應該溫習一下 這篇 有關如何在BlazeMeter中建立測試的文章.

將沙箱的測試配置設置成，用戶300，1個控制檯, 時間50分鐘.

對沙箱進行這樣的配置讓你能夠在後臺測試你的腳本，並確保上的BlazeMeter的一切都運行無缺.

爲此，先按下灰色的按鈕: 告訴JMeter引擎我想要徹底控制! - 來得到對你的測試參數的徹底控制

一般你將會遇到的問題:

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

2. 確保你全部的測試文件, 好比: CSVs, JAR, JSON, User.properties 等等.. 均可以使用

3. 確保你沒有使用任何路徑

若是仍然有問題，那就看看錯誤日誌吧(你應該能夠把整個日誌都下載下來).

一個沙箱的配置能夠是這樣的:

• 引擎: 是能使控制檯(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%佔有率的上限。

若是你的控制檯達到了該上限——減小引擎數量並從新運行直到控制檯在該上限之下。

在這個步驟的最後，你會發現：

    1. 每一個集羣的用戶數量；

    2. 每一個集羣的命中率。

查看Aggretate Table中的其餘統計信息，並找到本地結果統計圖來得到有關你集羣吞吐量的更多信息。

回到頂部

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

咱們到了最後一步了。

咱們知道腳本正在運行，咱們也知道一個引擎能夠支持多少用戶以及一個集羣能夠支持多少用戶。

讓咱們作一下假設：

• 一個引擎支持500用戶

• 一個集羣能夠用戶12個引擎

• 咱們的目標是5萬用戶測試

所以爲了完成這些，咱們須要8.3 個集羣..

咱們能夠用8個12臺引擎的集羣和一個4太引擎的集羣 - 可是像下面這樣分散負載應該會更好：

每一個集羣咱們用10臺引擎而不是12，那麼每一個集羣能夠支持 10*500 = 5K 用戶而且咱們須要10個集羣來支持5萬用戶。

這樣能夠獲得以下好處：

1. 不用維護兩個不一樣的測試類型

2. 咱們能夠經過簡單的複製現有集羣來增長5K用戶（5K比6K更常見）

3. 只要須要咱們能夠一直增長

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

1. 將測試的名稱從"My prod test" 改成"My prod test - slave 1"。

2. 咱們回到步驟5，將高級測試屬性(Advanced Test Properties)下的Standalone修改成Slave。

3. 按保存按鈕——如今咱們有了一個Master和9個Slave中的一個。

4. 返回你的 "My prod test -slave 1".

5. 按複製按鈕

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

7. 回到你的 "My prod test -salve 9" 並按複製按鈕.

8. 將測試的名稱改成 "My prod test -Master".

9. 將高級測試屬性(Advanced Test Properties) 下的Slave改成Master。

10. 檢查咱們剛纔建立的全部的Slave(My prod test -salve 1..9)並按保存。

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

你能夠修改任意一個測試（salve或master），讓它們來自不一樣的區域，有不一樣的腳本/csv/以及其餘文件，使用不一樣的網絡模擬器，不一樣的參數等。

你能夠在一個叫「Master load results」的master報告中的一個新tab頁中找到生成的聚合結果的報告，你還能夠經過打開單個的報告來獨立的查看每個測試結果。

本文地址：http://www.oschina.net/translate/how-run-load-test-50k-concurrent-users

原文地址：http://blazemeter.com/blog/how-run-load-test-50k-concurrent-users