基本公式
線程數=QPS*time
註:QPS–每秒完成請求的個數;time–每個請求響應完成平均需要時間
故QPS*time就是所有請求完成響應所需要的總時間,如果需要在一秒完成所有請求的響應,所以線程數需要等於總時間值
壓力測試線程數確定
比如一個活動,大概一個小時內有60w人的流量,算應該壓測的線程數是多少 ,一個小時=60分鐘=3600s
演算法
二八定律,20%的時間跑了80%的流量,換算就是 12分鐘跑了48w流量 48w/12/60~=667,就是設置集合點後,每秒應跑的線程數是667,當然也不是絕對的線程數需要一點一點往上壓主要看測試之前制定的指標
指標
每秒事務數、介面error率、響應時間、內存、cpu、網路、資源、jvm查看fgc情況和阻塞點。
壓力測試
壓力測試分兩種場景:一種是單場景,壓一個介面的;第二種是混合場景,多個有關聯的介面。壓測時間,一般場景都運行10-15分鐘。如果是疲勞測試,可以壓一天或一周,根據實際情況來定。
壓測任務需求的確認,壓測前要明確壓測功能和壓測指標,一般需要確定的幾個問題:
1.固定介面參數進行壓測還是進行介面參數隨機化壓測?
2.要求支持多少並發數?
3.TPS(每秒鐘處理事務數)目標多少?響應時間要達到多少?
4.壓伺服器名稱還是壓伺服器IP,一般都是壓測指定的伺服器?
壓測設置
線程數:並發數量,能跑多少量?具體說是一次存在多少用戶同時訪問
Rame-UpPeriod(inseconds):表示JMeter每隔多少秒發動並發。理解成準備時長:設置虛擬用戶數需要多長時間全部啟動。如果線程數是20,準備時長為10,那麼需要10秒鐘啟動20個數量,也就是每秒鐘啟動2個線程。
循環次數:這個設置不會改變並發數,可以延長並發時間。總請求數=線程數*循環次數
調度器:設置壓測的啟動時間、結束時間、持續時間和啟動延遲時間。

壓測結果查看
運行完後,查看結果樹可以查看介面成功與否 聚合報告會顯示壓測的結果。主要觀察Samples、Average、error、Throughput。
Samples:表示一共發出的請求數
Average:平均響應時間,默認情況下是單個Request的平均響應時間(ms)
Error%:測試出現的錯誤請求數量百分比。若出現錯誤就要看服務端的日誌,配合開發查找定位原因
Throughput:簡稱tps,吞吐量,默認情況下表示每秒處理的請求數,也就是指伺服器處理能力,tps越高說明伺服器處理能力越好。
壓測結果的分析
有錯誤率同開發確認,確定是否允許錯誤的發生或者錯誤率允許在多大的範圍內; Throughput吞吐量每秒請求的數大於並發數,則可以慢慢的往上面增加;若在壓測的機器性能很好的情況下,出現吞吐量小於並發數,說明並發數不能再增加了,可以慢慢的往下減,找到最佳的並發數; 壓測結束,登陸相應的web伺服器查看CPU等性能指標,進行數據的分析; 最大的tps:不斷的增加並發數,加到tps達到一定值開始出現下降,那麼那個值就是最大的tps。
最大的並發數:最大的並發數和最大的tps是不同的概率,一般不斷增加並發數,達到一個值後,伺服器出現請求超時,則可認為該值為最大的並發數。
壓測過程出現性能瓶頸,若壓力機任務管理器查看到的cpu、網路和cpu都正常,未達到90%以上,則可以說明伺服器有問題,壓力機沒有問題。
影響性能考慮點包括:資料庫、應用程序、中間件(tomact、Nginx)、網路和操作系統等方面。
原創文章,作者:投稿專員,如若轉載,請註明出處:https://www.506064.com/zh-tw/n/226771.html