使用的jmeter進行性能測試
先在本地編寫測試腳本，沒問題以后在服務器中運行
1.進入服務器jmeter的bin目錄下，非GUI模式下壓測：
2.運行：jmeter -n -t jmx腳本在服務器的存放路徑 -l jtl文件生成路徑
3.運行過程中可查看應用服務的日志，看是否報OOM等異常錯誤
4.注意：在運行腳本之前，需確定應用服務器與數據庫服務器中資源在上次腳本運行結束后已釋放。（應用服務器與數據庫服務器監控可與公司運維查看）
- 查看應用服務的CPU使用率與平均負載是否降至最低，
- 查看TCP連接數是否釋放，
- 查看內存使用率是否降至最低
5.運行結束后，需將運行時間段內的應用服務器與數據庫服務器的資源暫用情況進行收集（截圖），主要收集內容：
- 不同的場景
- 每個場景下收集的內
- 進行數據收集
性能測試報告
1.測試目的
評估XXXapp服務端常用接口當前最大性能並查找性能瓶頸。
2.環境
測試環境（服務、雲環境、ip地址、系統配置）
生產環境（服務、雲環境、ip地址、系統配置）----負載均衡
數據庫最大連接數、JVM參數設置
說明：
- 服務器配置與生產環境一致
- 數據庫鏈接數和JVM參數均與生產環境一致
- 測試環境模擬單節點進行測試，測試結果均為單節點4C16G配置性
3.被測接口
| 功能名稱 | 請求方法 | 接口地址 | 參數化 |
| 接口A | get | ||
| 接口B | get | 有，goodsId | |
| 接口C | get |
4.測試結果
接口A
測試場景及結果
| 場景 | 並發線程 | 運行時間 | samples | ART(ms) | 90%(ms) | QPS | ERROR |
| 場景一 | 5 | 600 | 588918 | ||||
| 場景二 | 10 | 600 | 954976 | ||||
| 場景三 | 15 | 600 |
|
測試分析
- 對比場景一與場景二，場景二QPS為，90%響應時間為Xms，系統資源均在正常范圍以內，如下圖所示
場景一應用服務器cpu使用情況
+CPU使用率圖
+CPU平均負載圖
場景二應用服務器cpu使用情況
+CPU使用率圖
- 觀察場景X運行期間，系統資源使用情況，應用服務器CPU利用率已經達到88%，CPU負載極不穩定，已經有超過10的情況，結合服務器配置為4C，說明應用服務器CPU已經出現瓶頸。其它資源使用正常
+應用服務器CPU利用率圖
+應用服務器CPU平均負載圖
+數據庫服務器CPU、TPS、qps圖
- 觀察場景X，X並發線程數，應用服務器cpu平均負載仍然達到10以上，且隨着場景運行有上升的趨勢，同時數據庫存在4次慢查詢
- 觀察系統資源使用情況，場景X，20並發線程數，應用服務器cpu平均負載已經達到X，說明CPU已經出現排隊現象
- 腳本執行過程中，后端日志異常出現內存溢出情況，導致錯誤率達到43.40%
- CPU負載接近10左右，內存使用率逐漸上升，如果場景持續運行，內存使用率將會爆滿
綜上所述，文章詳情接口，單節點最大QPS為XXX，90%響應時間為XXX
綜上所述，領券接口性能較差，有OOM異常，請開發排查定位！
結果匯總
| 接口 | 最大並發進程數 | 運行時間（s） | Samples | 90%ART(ms) | QPS | CPU | CPULOAD | MEM |
| 接口A | 10 | 600 | 862432 | 10 | 1437.6/s | 70% | 7.9 | 59.88% |
正式環境接口請求數據信息
| 日期 | 接口總訪問量 | 接口 | 訪問次數 | |
| 2020/07/03 | 6817 | 接口A | /api/.. | 568 |
每天接口訪問次數基本都在1000以下，生產環境壓力較小。相比較測試結果來看，當前接口均滿足生產環境性能需求。