前言

身為后端程序員怎么也要會一點壓力測試相關的技術吧, 不然無腦上線項目萬一項目火了進來大量請求時出現(xiàn)程序執(zhí)行緩慢, 宕機等情況你肯定穩(wěn)穩(wěn)背鍋, 而且這個時候短時間內還沒辦法解決, 只能使用物理擴容CPU, 內存, 更換網絡等幾種方式來解決問題, 妥妥的為公司增加支出好吧, 下一個被開的就是你

都是想跑路拿高薪的打工仔, 身上怎么可以背負污點, 趕緊學一手壓力測試進行保命, 我先學為敬

本篇文章主打一個學完就會, 奧利給

文中出現(xiàn)軟件的版本

• JMeter: 5.5

• ServerAgent: 2.2.3

性能調優(yōu)對各個開發(fā)崗位的區(qū)別

各個崗位對性能調優(yōu)的關鍵節(jié)點

• 前端工程師:

• 首屏時間: 初次訪問項目等待加載時間

• 白屏時間: 刷新頁面到數(shù)據(jù)全部展示時間

• 可交互時間

• 完全加載時間

• 后端工程師

• RT: 響應時間

• TRS: 每秒事務數(shù)

• 并發(fā)數(shù): 這應該不會解釋了吧

• 移動端工程師

• 端到端相應時間

• Crash率

• 內存使用率

• FPS

主要講一下后端工程師(Java), 畢竟這是吃飯的家伙
對于后端工程師來說, 影響性能的地方主要有兩個

• 數(shù)據(jù)庫讀寫, RPC, 網絡IO, 代碼邏輯復雜度, 緩存

• JVM(Throughput) - JVM(Throughput)

影響性能的關鍵要素

• 產品設計

• 產品邏輯

• 功能交互

• 動態(tài)效果

• 頁面元素

• 基礎網絡

• 代碼質量&架構

• 架構不合理

• 研發(fā)功底和經驗不足

• 沒有性能意識: 只實現(xiàn)功能不注重代碼性能, 當業(yè)務上量后系統(tǒng)出現(xiàn)連鎖反應, 導致性能問題增加

• 數(shù)據(jù)庫: 慢查詢, 過多查詢, 索引使用不當, 數(shù)據(jù)庫服務器瓶頸

• 用戶移動端環(huán)境

• 設備類型&性能

• 系統(tǒng)版本

• 網絡(WiFi, 2G, 3G, 4G, 5G)

• 硬件及云服務(服務器硬件, CPU, 內存..)

1. 初步了解壓力測試

1.1壓力測試是什么

go復制代碼壓力測試是針對特定系統(tǒng)或組件, 為要確定其穩(wěn)定性而特意進行的嚴格測試. 會讓系統(tǒng)在超過正常使用條件下運作, 然后再確認其結果 對系統(tǒng)不斷施加壓力, 來預估系統(tǒng)`負載能力`的一種測試 ?一般而言, 只有在系統(tǒng)基礎功能測試驗證完成, 系統(tǒng)趨于穩(wěn)定的情況下, 才會進行壓力測試

1.2壓力測試的目的

markdown復制代碼當負載主鍵增加時, 觀察系統(tǒng)各項性能指標的變化情況是否有異常 發(fā)現(xiàn)系統(tǒng)的性能短板, 進行針對性的性能優(yōu)化 判斷系統(tǒng)在**高并發(fā)情況下是否會報錯**, 進行是否會掛掉 測試在系統(tǒng)某個方面達到瓶頸時, 粗略估計系統(tǒng)性能上限

1.3 壓力測試的指標

指標含義相應時間(RT)是指系統(tǒng)對請求作出響應的平均時間, 對于單用戶的系統(tǒng), 響應時間可以很好地度量系統(tǒng)的性能吞吐量(Throughput)是指系統(tǒng)在單位時間內處理的數(shù)量, 每秒事務數(shù)TPS 也算是吞吐量的一種資源利用率CPU占用率, 內存使用率, 系統(tǒng)負載, 網絡IO并發(fā)用戶數(shù)是指系統(tǒng)可以同時承載的正常使用系統(tǒng)功能的用戶的數(shù)量, 用戶不同的使用模式會導致不同用戶在單位時間發(fā)出不同數(shù)量的請求錯誤率失敗請求占比, 在測試時添加響應斷言, 驗證不通過即標記為錯誤, 若不添加, 響應碼非200則為錯誤

評判系統(tǒng)性能, 主要考慮三個性能指標 RT, TPS, 資源利用率

上圖充分的展示了響應時間, 吞吐量, 利用率和并發(fā)用戶數(shù)之間的關系

隨著并發(fā)用戶的增加經過輕負載區(qū), 達到最優(yōu)并發(fā)數(shù), 此時利用率高,吞吐量高, 響應時間短

但是如果用戶數(shù)繼續(xù)增加, 就會到達重負載區(qū), 此時性能最大化, 但是當超過某一臨界值(最大并發(fā)數(shù))之后, 響應時間會急劇增加, 利用率平緩, 吞吐量急速下降

我們進行壓測的目的主要就是測試出這個臨界值的大小, 或者說, 我們系統(tǒng)當前能承受住的最大并發(fā)數(shù)

2. 壓力測試工具 JMeter

老規(guī)矩, 先來一波軟件介紹 JMeter是 Apache組織開發(fā)的基于 Java的開源壓力測試工具, 具有體積小, 功能全, 使用方便等特點. 最初被設計用于 Web應用測試, 后來被擴展到其他測試領域.

常用壓測工具:

• Apache JMeter可視化的測試工具

• LoadRunner 預測系統(tǒng)行為和性能的負載測試工具

• Apache的 ab壓力測試

• nGrinder韓國研發(fā)的一款性能測試工具

• PAS阿里測試工具

壓測目標:

• 負載上升各項指標是否正常

• 發(fā)現(xiàn)性能短板

• 高并發(fā)下系統(tǒng)是否穩(wěn)定

• 預估系統(tǒng)最大負載

2.1 安裝 JMeter

寫在前面, 需要 Java8環(huán)境, 沒有的話需要去安裝, 教程百度上一大堆

官網地址: jmeter.apache.org/

熟悉的download, 點他

開始下載(是真的慢)

解壓之后進入 bin目錄下, 雙擊 jmeter.bat, 就可以啟動 JMeter了

上圖可以看出, 在我們第一次打開界面時是英文的, 多少有點不友好, 接下來講解一下怎么將語言更改為中文

2.2 設置 JMeter界面為中文

還是我們的 bin目錄下, 有一個 jmeter.properties文件

雙擊打開, 搜索 language

去除 #號, 值更改為 zh_CN, 保存文件然后重啟軟件(雙擊jmeter.bat)

可以看到, 我們的 jmeter成功更改為了中文界面, 這對于我這種英語白癡來說是很舒服的

2.3 初步使用 JMeter

我們先隨便創(chuàng)建一個測試用例, 就是簡單測試, 同時講解一下常用的參數(shù)

本次測試采用 20線程, 1秒啟動時間, 循環(huán)100次, Get請求

2.3.1 創(chuàng)建線程組

• 線程數(shù): 虛擬的用戶數(shù), 一個用戶占一個線程

• Ramp-Up: 等待時間, 設置的虛擬用戶(線程數(shù))需要多長時間全部啟動

• 循環(huán)次數(shù): 單個線程發(fā)送請求的次數(shù)

• 調度器:

• 持續(xù)時間: 該任務執(zhí)行的時間

• 啟動延遲: 等待多少秒開始執(zhí)行

2.3.2 創(chuàng)建 http請求

右鍵線程組-添加HTTP請求

這個中文講解的很明白, 應該都看得懂的, 有疑問的評論區(qū)留言

2.3.3 結果樹

結果樹, 聚合報告, 圖形結果只有新增, 解釋在測試

線程組右鍵-添加-監(jiān)聽器-查看結果樹

執(zhí)行結果分析(啟動之后顯示界面)

列表列出了每一次的HTTP請求, 綠色的是成功, 紅色的話就是失敗

• 取樣器結果參數(shù)詳解

• Thread Name：線程組名稱

• Sample Start: 啟動開始時間

• Load time：加載時長

• Latency：等待時長

• Size in bytes：發(fā)送的數(shù)據(jù)總大小

• Headers size in bytes：發(fā)送數(shù)據(jù)的其余部分大小

• Sample Count：發(fā)送統(tǒng)計

• Error Count：交互錯誤統(tǒng)計

• Response code：返回碼

• Response message：返回信息

• Response headers：返回的頭部信息

• 請求

• 基本數(shù)據(jù)

• 入?yún)?/p>

• 請求頭

• 相應數(shù)據(jù)

• 響應碼

• 響應頭

2.3.4 聚合報告

線程組右鍵-添加-監(jiān)聽器-聚合報告

執(zhí)行結果分析(啟動之后界面)

參數(shù)解釋

• 樣本: 并發(fā)量

• 平均值: 接口請求用時(單位毫秒)

• 中位數(shù): 請求用時中位數(shù)(單位毫秒), 例如2000請求以請求時間排序, 排名1000的用時時長

• 90%百分位, 95%百分位, 99%百分位和中位數(shù)同理

• 最小, 最大值: 請求用時最小和最大

• 異常% : 請求中異常的百分比

• 吞吐量: 單位時間內請求次數(shù)

2.3.5 圖形結果

線程組右鍵-添加-監(jiān)聽器-圖形結果

執(zhí)行結果分析(啟動之后顯示界面)

• 樣本數(shù)目：總共發(fā)送到服務器的請求數(shù)。

• 最新樣本：代表時間的數(shù)字，是服務器響應最后一個請求的時間。

• 吞吐量：服務器每分鐘處理的請求數(shù)。

• 平均值：總運行時間除以發(fā)送到服務器的請求數(shù)。

• 中間值：有一半的服務器響應時間低于該值而另一半高于該值。

• 偏離：表示服務器響應時間變化、離散程度測量值的大小。

2.3.6 斷言

斷言主要用來判斷結果返回是否符合預期

線程組右鍵-添加-斷言-響應斷言

假設我們接口的返回狀態(tài)碼字段為code, 200為成功, 那么就可以在斷言這里進行配置, 來判斷請求是否成功

3. JMeter插件

3.1 插件安裝

首先說明 JMeter是不支持插件的, 所以我們先要 JMeter的插件允許插件下載, 這句話多少有點拗口

網址: Install :: JMeter-Plugins.org

點擊上圖紅框即可下載插件, 前面說過了 JMeter是 Java8開發(fā)的, 插件對應的也是一個 jar包

下好之后就可以放在 JMeter安裝目錄下的 lib/ext/ 下了, 具體下載頁面也有說明

上述操作結束之后, 在選項里面就可以看到插件中心Plugins Manager

彈出以下界面, 點擊 Available Plugins搜索我們需要的插件Basic Graphs和Additional Graphs, 勾選上, 然后安裝

Basic Graphs主要顯示顯示平均響應時間，活動線程數(shù)，成功/失敗交易數(shù)等

Additional Graphs主要顯示吞吐量，連接時間，每秒的點擊數(shù)等

在安裝成功之后, 在監(jiān)聽器會相應的多出很多的 jc開頭的, 這就代表安裝成功了

我使用的是 5.5版本的, 之前版本安裝之后好像要手動重啟, 5.5安裝完會自動重啟

4. Linux硬件監(jiān)控

在壓測過程中, 我們需要實時了解服務器的CPU, 內存, 網絡, 服務器負載等情況的變化, 這個時候我們就需要對我們的 Linux系統(tǒng)進行監(jiān)控, 通常來講, 我們查詢 Linux系統(tǒng)的資源占用情況可以使用以下幾種方法

• 使用命令: top, iostat, iotop等

• 使用 Linux遠程連接工具 FinalShell等

• 寶塔

• JMeter壓測工具 PerfMon

在 JMeter中, 如果需要監(jiān)控服務器硬件, 那么我們還需要安裝 PerfMon插件

PerfMon監(jiān)控服務器硬件，如CPU，內存，硬盤讀寫速度等

進入下述地址開始下載監(jiān)控包: github.com/undera/perf…

下載好之后我們可以直接解壓放到服務器上, 會看到有兩個startAgent文件, 分別是Windows系統(tǒng)和Linux系統(tǒng)的啟動腳本

我們直接啟動就可以了, 如果腳本啟動連接不上的話可以考慮更改腳本內容

例: Linux系統(tǒng)腳本更改為以下內容

sh復制代碼## 默認啟動運行 startAgent.sh 腳本即可 ?## 服務啟動默認4444端口，根本連接不上，因此自己創(chuàng)建一個部署腳本文件對此進行部署，且把端口修改為7879 ?nohup java -jar ./CMDRunner.jar --tool PerfMonAgent --udp-port 7879 --tcp-port 7879 > log.log 2>&1 & ?## 賦予可執(zhí)行權限 ?chmod 755 startAgent.sh

啟動成功之后, 腳本同級路徑下會多出 log.log的日志文件

然后我們就可以配置 JMeter了, 線程組-監(jiān)聽器-jp@gc - PerfMon Metrics Collector

我是在本地啟動了ServerAgent.bat進行測試, 執(zhí)行結果如下所示:

注: 文件必須配置, 不然沒有圖像

具體的配置指標信息建議看官方文檔, 太多了.... github.com/undera/perf…

ServerAgent閃退問題

Windows系統(tǒng)配置好ServerAgent啟動之后窗口閃退可能是 jre版本問題, 可以從下面的鏈接下載老版的 jre

www.aliyundrive.com/s/Yzw3DZ74w…

下載好之后, 建議安裝目錄設置在ServerAgent/jre下

并更改startAgent.bat腳本, cd 到老版本 jre路徑