前言

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

下載安裝Jmeter

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

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

解壓出來就算裝好了。

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

安裝相關插件

下載插件管理工具

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

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

安裝性能測試相關插件

打開插件管理工具（選項->Plugins Manager->Available Plugins）

根據需求勾選以下插件：

插件名	-
Custom Thread Groups	- 個人覺得最好用的性能測試線程組
3 Basic Graphs	- 活動線程數變化曲線
-	- 響應時間變化曲線
-	- 每秒事務處理率（TPS）
Composite Timeline Graph	- 把多個圖形監聽器組合起來
PerfMon (Servers Performance Monitoring)	- 遠程監聽服務器資源使用率
Command-Line Graph Plotting Tool	- 可以手動把jtl或csv文件轉化成圖片（主要用於PerfMon結果生成圖形）

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

安裝監控服務器資源程序

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

往下拉，在Installation中點擊here，進入下載頁面

點擊下載最新版。

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

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

設計一個性能測試腳本

性能測試場景

用戶定義變量配置元件，可以設置一些環境變量，讓我們快速切換測試環境。

我喜歡再定義一個HTTP請求默認值配置元件，因爲這樣之後的Sampler就不用再寫協議、IP和端口號了

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

性能測試監聽器

每秒活動線程變化，基本和設置的場景一致

每秒響應時間變化

每秒事務處理率（TPS）

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

服務端CPU和RAM
這裏因爲測試對象也在本地，所以寫的localhost，實際應該填寫運行ServerAgent的服務端地址。

硬盤I/O和網絡I/O
建議和CPU分開來監聽，因爲CPU和RAM峯值100，而I/O峯值數百萬。放在一起看起來不方便。

如果你需要使用PerfMon監聽器，那麼建議你在測試計劃中定義一個腳本路徑地址的變量。__P()函數用來用cmd接收參數。然後在PerfMon監聽器中，使用這個路徑，把監聽結果保存成文件。這樣配置後，我們通過非GUI模式運行腳本時，可以把服務器資源使用情況轉化成圖表。

編寫啓動器

根據我長期以來經驗，並不斷完善，我建議可以參考我寫的批處理腳本

生成當前日誌是爲了多次測試結果不覆蓋，並保留歸檔
配置地址 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

如果不用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

以上寫法是把腳本和測試結果放在一個路徑下的。如果要把測試報告放在其他地址下（譬如放到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

性能測試過程

執行測試

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

執行完之後就會有一個日期文件夾來存放本次測試結果

直接把PerfMon中的CPU等信息轉化成了圖片。

測試報告

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

每秒活動線程變化

每秒響應時間變化

每秒事務處理率（TPS）

分析測試結果

理論

分析

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

隨着用戶數越來越多，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。

總結

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

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

Jmeter從下載到完成性能測試實戰教程（Windows平臺）

目錄

前言