前面幾篇文章已經介紹完成的一個電商從註冊登錄到購物下單的典型場景的
Jmeter
壓測腳本,具體可參考文章:
基於電商模式的性能測試(五)-基於Jmeter完成一次日常典型電商場景的壓測(下單-支付)
1、場景調整
在實際壓測前,我們還需要對場景做適當的調整
1.1 調整目的
從Thread Group
中看,我們的Thread
會在某個時間點同時起多個,而日常場景中我們需要的可能是一個遞增的梯度加壓的方式
爲了實現梯度遞增,我們就需要藉助於插件Ultimate Thread Group
1.2 Ultimate Thread Group插件簡介
- 先看下
Ultimate Thread Group
插件的面板信息,如下:
- 參數解釋:
-
Start Threads Count
:當前行啓動的線程總數 -
Initial Delay/sec
:延時啓動當前行的線程,單位:秒 -
Startup Time/sec
:啓動當前行所有線程達峯值所需時間,單位:秒 -
Hold Load For/sec
:當前行線程達到峯值後的穩定加載時間,單位:秒 -
Shutdown Time
:停止當前行所有線程所需時間,單位:秒
-
- 文字的描述還是稍顯晦澀,
Ultimate Thread Group
插件有個很好的地方就是下方的圖表,它會根據你的設定而展示出趨勢圖,那麼現在我們設定如下參數:-
Start Threads Count
:100 -
Initial Delay/sec
:10秒 -
Startup Time/sec
:200秒 -
Hold Load For/sec
:100秒 -
Shutdown Time
:10秒
從插件的趨勢圖我們可以看到在延遲10秒後100個線程在200秒時間內逐步從0遞增至100,然後持續100秒的時間,最後在10秒的時間內有逐步從100遞減到0.
-
- 當然你還可以繼續添加
Thread Schedule
,趨勢圖會幫你繪製出綜合的線程運行趨勢:
1.3 調整方式
介紹完
Ultimate Thread Group
插件,要開始實操調整我們的電商壓測腳本了
1) 選擇插件Ultimate Thread Group
2)將寫好的Jmeter腳本整體移至Ultimate Thread Group
下
3)現在我們需要的場景是:
- 開始我們需要在60秒的時間內起是10個thread,然後保持運行
- 接着我們繼續在60秒的時間內再起10個thread,然後和開始的10個線程一起保持運行100秒後結束
具體設置如下:
2、實操演示
2.1 運行
1)命令啓動,實際運行腳本期間會用命令行的方式,減少客戶端自身運行性能造成的測試影響
$ jmeter -n -t RegisterLogin.jmx
2)在grafana中查看運行數據
2.2 數據分析
從數據中簡單的分析,可以看到:
- 線程數在設定的120秒時間內均勻的從0遞增至20
- 錯誤率在38分30秒的時候出現劇增,而這個時候的線程數爲5,說明在
Active User
達到5的時候系統出現了問題造成錯誤率陡增
- 從錯誤率和響應時間來看,結果較差的接口主要集中在下單流程這塊,而首頁的響應時間也很大,很可能是因爲首頁相關的表數據是和訂單的表數據有關聯的,因而訂單的響應時間增加也會造成首頁的耗時增加。
2.3 補充說明-AutoStop Listener插件
2.3.1 AutoStop Listener簡介
在實際的測試中,可能還需要設置觸發點,假如請求的響應時間過長,錯誤率過大,已經沒有測試的必要了後自動停止測試,這個時候就可以藉助另外一個插件——
AutoStop Listener
- 插件添加後在如下位置選擇
注:因爲本片文章的重點不是介紹Jmeter插件體系,所以省略了插件的安裝說明和原理等,可自行查閱資料或待後續補充相關文章,我本人在這塊也是入門級別,在踩坑學習中~
- 打開後的面板如下:
- 現在可以設置當平均響應時間大於200ms持續10秒,平均延遲時間大於300ms持續10秒或者錯誤率大於1%持續5秒時測試停止
2.3.2 運行效果
- 可以看到當我們的響應時間持續10秒超過200ms時,測試自動停止了
3、寫在最後
客戶端方面的電商壓測實戰學習就暫時到這裏了,後面如果還想繼續深入學習就需要關注服務端的指標了,依然可以結合docker+grafana+prometheus
的方式來監控服務端的各項指標進行分析,這裏先保留位置,如果後續我學習瞭解清楚將再次繼續更新我的筆記鏈接:
待補充學習——基於電商模式的性能測試-服務端性能監控與分析