前言

本教程內容龐大，所以儘量寫的精簡，沒有寫出指令碼的具體編寫步驟，有興趣的朋友可以下載Demo後和教程對照著看。
請求的服務端，是通過服務端模擬器來生成的。可以下載Mock服務端模擬器，設定與教程相同的請求地址來學習。
Demo下載地址：點選下載
Mock服務端模擬器：點選下載

下載安裝Jmeter

計算機上已裝好Jmeter的請跳過此步驟。本教程是根據Jmeter5.0編寫的，其他版本可能有出入。

1. 訪問官網並下載，培養大家自己動手的習慣，就不給出官網連結了，自己百度吧。
   Binaries的意思是發行版。Source是原始碼，用於二次開發。

2. 解壓出來就算裝好了。

3. 配置環境變數（計算機右鍵->屬性->高階系統設定->環境變數）
   新建一個環境變數 變數名JMETER_HOME 變數值：你解壓出來的目錄
   編輯Path變數 追加一段內容;%JMETER_HOME%\bin

安裝相關外掛

下載外掛管理工具

1. 百度一下jmeter plugins找到Jmeter外掛官網，下載plugins-manager.jar（外掛管理工具）

2. 下載好了之後，放進Jmeter安裝路徑的/lib/ext目錄下，再重啟Jmeter

安裝效能測試相關外掛

1. 開啟外掛管理工具 （選項->Plugins Manager->Available Plugins）

4. 根據需求勾選以下外掛：

*以上外掛都是按需勾選，譬如你的伺服器是放在阿里雲上的，自帶了資源監控，就不需要PerfMon外掛了。

安裝監控伺服器資源程式

1. PerfMon還需要額外的一個程式：ServerAgent 它的功能是獲取當前計算機的CPU、RAM、I/O等使用情況
   我們在外掛中找到，訪問它的介紹頁面

2. 往下拉，在Installation中點選here，進入下載頁面

3. 點選下載最新版。

4. 這是一個獨立程式，它需要放到伺服器上執行，然後測試過程中監聽伺服器的資源使用情況。
   *建議本地也放一份，這個後面會用到。

5. 再次強調，這個程式是應該放在被測物件機器上的。
   *這裡用於演示，請求的是127.0.0.1的地址，所以就在本機運行了。實際工作中客戶機和伺服器肯定是分開的。

設計一個性能測試指令碼

效能測試場景

1. 使用者定義變數配置元件，可以設定一些環境變數，讓我們快速切換測試環境。

3. 我喜歡再定義一個HTTP請求預設值配置元件，因為這樣之後的Sampler就不用再寫協議、IP和埠號了

4. Concurrency Thread Group 最好用的效能測試場景執行緒組
   Target Concurrency是 匯流排程數
   Ramp Up Time(min) 是 總執行時間（單位分鐘）
   Ramp-Up Steps Count 是份數
   Hold Target Rate Time(min)是保持執行時間
   實際意義就是，總共啟動500個執行緒，執行5分鐘，分成10個階段啟動，最後持續0分鐘結束。

效能測試監聽器

1. 每秒活動執行緒變化，基本和設定的場景一致

2. 每秒響應時間變化

3. 每秒事務處理率（TPS）

4. 組合圖形
   結合以上3個監聽器我們可以看出，隨著活動執行緒數的不斷增加，響應時間越來越高，但TPS保持穩定沒有太大變化。

5. 服務端CPU和RAM
   這裡因為測試物件也在本地，所以寫的localhost，實際應該填寫執行ServerAgent的服務端地址。

6. 硬碟I/O和網路I/O
   建議和CPU分開來監聽，因為CPU和RAM峰值100，而I/O峰值數百萬。放在一起看起來不方便。

7. 如果你需要使用PerfMon監聽器，那麼建議你在測試計劃中定義一個指令碼路徑地址的變數。__P()函式用來用cmd接收引數。然後在PerfMon監聽器中，使用這個路徑，把監聽結果儲存成檔案。這樣配置後，我們通過非GUI模式執行指令碼時，可以把伺服器資源使用情況轉化成圖表。

編寫啟動器

1. 根據我長期以來經驗，並不斷完善，我建議可以參考我寫的批處理指令碼

• 生成當前日誌 是為了多次測試結果不覆蓋，並保留歸檔
• 配置地址 jmxPath是為了把PerfMon監聽器結果儲存，否則直接用.就能獲取到當前路徑了。
  jmeterPath也是為了把PerfMon監聽器的結果轉化成圖表圖片。
• 建立日期資料夾 用於存放測試結果
• 執行Jmeter
• 生成監聽器截圖 （*Jmeter5.0必須要安裝"Command-Line Graph Plotting Tool"外掛，才能用這個命令）
• 日誌存檔 把JMeter.log檔案放入日期資料夾。建立Release資料夾，用於儲存最新測試結果。

@echo off

rem 生成當前日期
set date=%date:~0,4%%date:~5,2%%date:~8,2%
if "%time:~0,2%" lss "10" (set hour=0%time:~1,1%) else (set hour=%time:~0,2%)
set time=%hour%%time:~3,2%%time:~6,2%
set d=%date%%time%
echo 當前日期: %d%

rem 配置地址
set jmxPath="E:\Desktop\博文\Demo"
set jmeterPath="F:\apache-jmeter-5.0"

rem 建立日期資料夾
mkdir %jmxPath%\%d%
if not exist %jmxPath%\%d%\PerfMon mkdir %jmxPath%\%d%\PerfMon >nul

rem 執行Jmeter
call jmeter -JjmxPath="%jmxPath%\%d%" -n -t %jmxPath%\Demo.jmx -l %jmxPath%\%d%\Result.jtl -e -o %jmxPath%\%d%\Report

rem 生成監聽器截圖（需要修改版本號）
call java -jar %jmeterPath%\lib\cmdrunner-2.2.jar --tool Reporter --generate-png %jmxPath%\%d%\CPUMemory.png --input-jtl %jmxPath%\%d%\PerfMon\CPUMemory.jtl --plugin-type PerfMon
call java -jar %jmeterPath%\lib\cmdrunner-2.2.jar --tool Reporter --generate-png %jmxPath%\%d%\IO.png --input-jtl %jmxPath%\%d%\PerfMon\IO.jtl --plugin-type PerfMon

:: 日誌存檔
move %jmxPath%\jmeter.log %jmxPath%\%d% >nul
if not exist %jmxPath%\Release mkdir %jmxPath%\Release >nul
xcopy /Y %jmxPath%\%d% %jmxPath%\Release /s /f /h >nul

:: pause

2. 如果不用PerfMon外掛、不需要生成CPU&RAM等資源情況，可以參考這種寫法

@echo off

rem 生成當前日期
set date=%date:~0,4%%date:~5,2%%date:~8,2%
if "%time:~0,2%" lss "10" (set hour=0%time:~1,1%) else (set hour=%time:~0,2%)
set time=%hour%%time:~3,2%%time:~6,2%
set d=%date%%time%
echo 當前日期: %d%

rem 建立日期資料夾
mkdir %d%

rem 執行Jmeter
call jmeter -n -t Demo.jmx -l %d%\Result.jtl -e -o %d%\Report

:: 日誌存檔
move jmeter.log %d% >nul
if not exist Release mkdir Release >nul
xcopy /Y %d% Release /s /f /h >nul

:: pause

3. 以上寫法是把指令碼和測試結果放在一個路徑下的。如果要把測試報告放在其他地址下（譬如放到Jenkins上，肯定要測試結果和指令碼分離了），可以做相應修改。同時還可以對多餘測試報告進行清除。

@echo off

rem 生成當前日期
set date=%date:~0,4%%date:~5,2%%date:~8,2%
if "%time:~0,2%" lss "10" (set hour=0%time:~1,1%) else (set hour=%time:~0,2%)
set time=%hour%%time:~3,2%%time:~6,2%
set d=%date%%time%
echo 當前日期: %d%

rem 配置地址
set reportPath="E:\Desktop\API_TEST_RESULT"

rem 建立日期資料夾
mkdir %reportPath%\%d%

rem 執行Jmeter
call jmeter -n -t Demo.jmx -l %reportPath%\%d%\Result.jtl -e -o %reportPath%\%d%\Report

:: 日誌存檔
move jmeter.log %reportPath%\%d% >nul
if not exist %reportPath%\Release mkdir %reportPath%\Release >nul
xcopy /Y %reportPath%\%d% %reportPath%\Release /s /f /h >nul

:: 清除多餘歷史測試報告
for /f "skip=8 delims=" %%a in ('dir /b /ad /o-d "%reportPath%"\*') do @rd /s /q "%reportPath%"\"%%a" && echo del %%a

:: pause

效能測試過程

執行測試

1. 有了批處理程式，我們可以快速的調整和反覆執行不同場景。
   前面演示為了方便，實際上我們通常把執行緒組裡的引數（匯流排程數、總時間、切割份數）也用__P()函式來傳遞。這樣我們放到Jenkins服武器上或需要多次執行時，只需要修改.bat中的引數就可以改變執行的場景。

2. 執行完之後就會有一個日期資料夾來存放本次測試結果

4. 直接把PerfMon中的CPU等資訊轉化成了圖片。

測試報告

1. 報表部分有PASS率、平均響應時間、90%響應時間等資訊。如果有錯誤，下方也有錯誤資訊。
   為什麼我的報告是中文，你的報告是英文？因為我自己漢化了。
   漢化方法見：https://blog.csdn.net/tomoya_chen/article/details/56481479
   最新完全漢化包：下載頁面

2. 每秒活動執行緒變化

3. 每秒響應時間變化

4. 每秒事務處理率（TPS）

分析測試結果

1. 理論

2. 分析

以剛才的測試報告為例，由於測試時間比較短，尾部釋放執行緒階段不參考。但仍然可以看出一些趨勢。

• 隨著使用者數越來越多，TPS也越來越高，但是在33分開始趨於平緩。甚至在34分開始，明明活動執行緒數上升，但TPS反而下降的不合理情況。
• 34分響應時間變化倒是不太明顯，但是在35分開始急劇上升了，此時TPS也是繼續下降，活動執行緒數為500。

如果忽略指令碼釋放執行緒的部分，可以得出初步結論，系統最多能支援每秒處理22個事務，即TPS=22，此時對應的使用者數在每秒250~300人。更多使用者的情況下，系統還不至於崩潰，但響應時間會很慢。

所以，這就是真實結果了嗎？不是，我們再來看一下CPU情況。

• 伺服器CPU一直在65%~75%之間，在剛才分析結果的拐點區仍然沒有繼續升高。這說明伺服器並沒有太吃力。

什麼原因呢？有可能有以下幾種情況：

• 測試機本身機能受限，測試過程中自己都卡的不行了，導致發出到伺服器的請求沒有那麼密集，沒有產生那麼大的壓力。
• 網路I/O的問題，網路頻寬上下行滿了，導致響應時間變長，但本身伺服器效能空閒。
• 伺服器對請求的IP或終端有特殊處理，限制 了最大TPS。
• 其他

效能測試易學難精，跑完指令碼給開發看固然簡單，但自己分析的話需要的知識面非常廣，但是響應時間就包含了七八層。我推測本次測試應該是第1種情況，因為NET I/O並不高。還需要加大執行緒數、延長測試時間繼續測試來觀察一下，甚至需要用到分散式方法進行測試。第四種情況是之前測試一個WebSocket介面時發現，服務端對單個終端發出的請求會限制TPS。當時我的解決辦法是寫了一個併發啟動指令碼，讓一臺機器跑20個jmeter指令碼，8臺機器模擬160個終端，最終才測出伺服器的TPS在1400多，否則無論怎麼測都是20TPS。

3. 總結

Jmeter在規範了外掛管理之後，把活動執行緒數、響應時間、TPS打包成一個3 Basic Graphs。就是因為日常測試中基本就是靠這3個監聽器完成初步分析。而為什麼監聽伺服器資源也很重要呢？Jmeter在規範了外掛管理之後，把活動執行緒數、響應時間、TPS打包成一個3 Basic Graphs。就是因為日常測試中基本就是靠這3個監聽器完成初步分析。而為什麼監聽伺服器資源也很重要呢？

因為：
1.我們要驗證測試結果是否準確。
2.真的對伺服器造成壓力了，我們要找到CPU滿載的那個時間點。再結合以上3個監聽器一起分析。