面試總被問高併發負載測試，你真的會麼？

本文將介紹使用50k併發用戶測試輕鬆運行負載測試所需的步驟（以及最多200萬用戶的更大測試）。

❶寫你的劇本

❷使用JMeter在本地測試

❸BlazeMeter SandBox測試

❹使用一個控制檯和一個引擎設置每引擎用戶數量

❺設置和測試羣集（一個控制檯和10-14個引擎）

❻使用主/從功能達到最大CC目標

第1步：編寫腳本

在開始以前，請確保從JMeter Apache社區獲取最新的JMeter版本。

在開始以前，您須要下載JMeter插件管理器。下載JAR文件後，將其放入JMeter的lib / ext目錄。而後，啓動JMeter並轉到「選項」菜單以訪問插件管理器。

有不少方法能夠得到你的腳本：

使用BlazeMeter Chrome擴展程序記錄您的方案；

使用JMeter HTTP（S）測試腳本記錄器， 您能夠設置代理，運行測試並記錄全部內容；

從頭開始手動操做並構建全部內容（可能用於功能/ QA測試）。

若是您的腳本是錄製的結果（如步驟1和2），請記住：

您須要更改某些參數，例如用戶名和密碼，或者您可能但願設置包含這些值的CSV文件，以便每一個用戶均可以是惟一的。

您可能須要使用正則表達式，JSON路徑提取器，XPath Extractor提取諸如Token-String，Form-Build-Id等元素，以便以「AddToCart」，「Login」等方式完成請求。

保持腳本參數化並使用配置元素（例如HTTP請求默認值），以便在環境之間切換時更輕鬆。

第2步：本地測試

使用View Results Tree元素，Debug Sampler，Dummy Sampler和打開的Log Viewer（若是報告了一些JMeter錯誤），使用一個線程，一次迭代開始調試腳本。

遍歷全部場景（真實和錯誤的響應）以確保腳本按預期運行。

使用一個線程成功運行腳本後，將其提高到10-20個線程10分鐘並檢查：

若是你打算讓每一個用戶都是獨一無二的 – 就是這樣嗎？你有任何錯誤嗎？

若是您正在進行註冊過程，請查看您的後端 – 是否根據您的模板建立了賬戶？它們是獨特的嗎？

從摘要報告中，您能夠看到有關測試的統計信息 – 它有意義嗎？尋找平均響應時間，錯誤，命中率/秒。

一旦你的腳本準備好了，經過刪除任何Debug / Dummy Samplers並刪除腳本偵聽器來清理它。

若是您使用監聽器（例如「保存對文件的響應」），請確保您不使用任何路徑！若是是監聽器或CSV數據集配置，請確保不使用本地使用的路徑。而是僅使用文件名，就好像它與腳本位於同一文件夾中同樣。

若是您使用本身專有的JAR文件，請務必上傳它。

若是您使用多個線程組（或不是默認線程組），請確保在將值上載到BlazeMeter以前設置這些值。

第3步：BlazeMeter SandBox測試

若是這是你的第一個測試，你應該反省這個文章，瞭解如何在BlazeMeter建立測試。

SandBox它其實是任何具備多達300個用戶的測試，而且使用一個控制檯最多隻需50分鐘。

SandBox的配置容許您測試腳本和後端，以確保BlazeMeter的一切正常。

要作到這一點，首先，按下灰色按鈕：JMeter引擎我想要徹底控制！徹底控制您的測試參數。

您可能遇到的常見問題包括：

防火牆 – 確保您的環境對BlazeMeter CIDR列表（正在不更新）開放並將它們列入白名單

確保存在全部測試文件，例如CSV，JAR，JSON，User.properties等

確保您沒有使用任何路徑

若是仍然遇到問題，請查看日誌中的錯誤（您應該能夠下載整個日誌）。

SandBox配置能夠是：

引擎：僅限控制檯（一個控制檯，0個引擎）

主題：50-300

加速：20分鐘

迭代：測試永遠持續下去

持續時間：30-50分鐘

這將容許您在加速期間得到足夠的數據（若是您在那裏遇到一些問題），您將可以分析結果以確保腳本按預期執行。

您應該查看Waterfall / WebDriver選項卡以查看請求是否正常。此時你不該該獲得任何錯誤（除非你的意圖）。

您應該觀察監控選項卡以查看使用了多少內存和CPU – 這將幫助您完成步驟4，同時您將嘗試設置每一個引擎的用戶數。

第4步：設置每一個引擎的用戶數量

既然咱們確信劇本在BlazeMeter中完美運行，咱們須要弄清楚咱們能夠將多少用戶應用於一個引擎。

若是您可使用SandBox數據來肯定，那太好了！

在這裏，我將爲您提供一種方法來解決這個問題，而無需回顧SandBox測試數據。

將測試配置設置爲：

線程數：500

加速40分鐘

迭代：永遠

持續時間：50分鐘

接下來，使用一個控制檯和一個引擎。

運行測試並經過Monitoring選項卡監控測試引擎。

若是您的引擎沒有達到75％的CPU利用率或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,2,3等）小時的全長進行測試。測試運行時，請轉到監控選項卡並驗證：沒有一個引擎經過75％的CPU或85％的內存限制。

找到您的控制檯標籤。若是您將轉到「日誌」選項卡 – >「網絡信息」並查找控制檯的專用IP，則能夠找到其名稱。它不該達到75％的CPU或85％的內存限制。

若是您的控制檯達到了該限制，請減小引擎數並再次運行，直到控制檯處於這些限制範圍內。

在此步驟結束時，您知道：

您將擁有的每一個羣集的用戶

您將達到的每一個羣集的點擊次數

在負載結果圖下的聚合表中查找其餘統計信息，以獲取有關羣集吞吐量的更多信息。

第6步：使用主/從功能達到最大CC目標

咱們已經到了最後階段。

咱們知道腳本正在運行，咱們知道一個引擎能夠維持多少用戶，而且咱們知道咱們能夠從一個羣集得到多少用戶。

咱們假設咱們有這些值：

一個引擎能夠擁有500個用戶

該集羣將有12個引擎

咱們的目標是進行50k測試

所以，要作到這一點，咱們須要建立50,000 （500 * 12）= 8.3個集羣。

咱們可使用8個集羣的12個引擎（48K）和一個集羣，其中有4個引擎（另外2個）。可是，最好像這樣分散負載：

咱們將使用10代替每一個集羣12個引擎，所以咱們將從每一個集羣得到10 * 500 = 5K，而且須要10個集羣才能達到50k。

這將有助於咱們：

不保持兩種不一樣的測試類型

過簡單地複製現有的集羣，咱們能夠增加5k（5k比6k更常見）

若是須要，咱們能夠隨時添加更多。

咱們如今準備用50k用戶建立咱們的最終主/從測試：將測試名稱從「個人產品測試」更改成「個人產品測試 – 從屬1」。

所以，咱們回到第5步中的測試，在高級測試屬性下，咱們將其從Standalone更改成Slave。

按保存，咱們如今有九個奴隸和一個主人中的第一個。

回到你的「個人產品測試-slave 1.」

按複製。

如今，重複步驟1-5，直到建立全部九個從屬。

回到你的「個人prod test -salve 9」並按下Duplicate。

將測試名稱更改成「My prod test -Master」。

轉到「高級測試屬性」並將其從「從」更改成「主」。

檢查咱們剛剛建立的全部從站（個人prod test -salve 1-9）並按save。

您對50k用戶的主從測試已準備就緒。經過按下主站上的啓動，您將啓動10個測試（一個主站和九個從站），每一個測試具備5k個用戶。

您能夠將每一個測試（從站或主站）更改成來自不一樣的區域，具備不一樣的腳本/ csv /其餘文件，使用不一樣的網絡仿真和/或不一樣的參數。

您的主服務器和從服務器的彙總報告將在主報告中的新選項卡中找到，稱爲「主加載結果」，您仍然能夠經過打開報告來查看每一個單獨的測試結果。