体育外围

体育外围
分享体育外围官网與網絡優惠

如何做壓力測試?

壓測的一般流程和方法是什么?需要關注哪些數據指標?如何推算后端需要支持的qps?本文分享總結壓測過程中需要注意的問題,希望對同學們有所啟發,歡迎討論。

一? 壓測目標
在開始做壓測計劃之前,一定要先明確壓測的目標是什么,雖然最終的目標肯定都是優化系統的性能,但是不同的出發點,可能需要采取不同的方法。
一般來說,可能有以下一些目的:
?
1? 挖掘系統瓶頸點,優化系統性能
?
尤其對新系統上線,缺乏性能基線數據,此時壓測一般沒有明確的qps/rt等指標,而是通過不斷施壓,不斷逼近系統的極限,從而暴露問題,修復問題。
?
2? 建立性能基線
?
主要是為了收集系統當前的最大性能指標,一般會根據業務特點,先確定對rt和錯誤率的容忍度,然后通過壓測推算出能夠支持的最大qps, 并發量等。
?
同時可以結合性能指標和監控數據,來建立合理的預警機制,設立系統水位報警項,限流閾值,彈性策略等。
?
量化系統能力/SLA等 (比如在競標中引用)。
?
3? 性能回歸
對于已上線系統,或者性能需求明確的系統,可以根據線上實際的運行情況,確定系統需要支撐的qps/rt, 然后在涉及性能影響前做回歸校驗,確保性能滿足預期。
?
4? 系統穩定性
更側重在一定壓力的情況下,系統是否能長時間穩定持續的提供SLA保障。
?
一般可以考慮將壓力設定到業務峰值的80%,持續施壓。
5? 網絡/線路延遲穩定性等
?
在一些特殊的業務場合,對延遲的容忍度極小,比如DNS解析,CDN服務,多人實時在線游戲,高頻交易等等,需要網絡質量,尤其是不同線路(電信/聯通/教育網/…)間的差異。
?
二? 壓測對象
明確了壓測目標后 ,就是確定要壓什么,來實現目標。
?
一般來說,壓測對象可以這么分:

  • 后端
  • 單api
  • 單業務邏輯場景
  • 前端
  • 單request
  • 單操作
  • 單頁
  • 整體頁面平均情況
?
三? 壓測數據
?
壓測過程中,一般主要關注一下數據指標:
1? starter/client
?

最重要的三個指標:
  • qps
  • rt
  • 成功率
?
其他的:
  • 頁面平均響應時間 (重要)。
  • 并發量(其實沒那么重要,主要還是qps)。
  • 最大用戶同時在線數 (用戶登錄系統,一般不需要額外壓測,除非業務場景特殊)。
  • 網絡質量(延遲,波動等,不展開)。
2? server
?
主要是監控數據:

  • cpu usage
  • load
  • mem
  • jvm/fullGC
  • 連接數(netstat)
  • disk io (iostat / iotop)
?
四? 壓測結果分析
?
一般是隨著壓力的增加(并發請求的增加)探究qps/rt/成功率三者的關系,從而找到系統的平衡點,如果能結合服務端的監控數據,就更好。
五? 壓測工具
?
1? jmeter
?
concurrent Thread Group
?
?
java sampler
?
composite chart
可以將多個chart組合到一個chart中,并且坐標系會自動伸縮,方便在一個圖中展示結果。
六? 性能指標推算方法
以上都是一些系統向的指標數據,其實對用戶來說是不感知,或者說也是沒有意義的。那什么樣的數字是有意義的呢?舉個例子:
  • 如果你提供的是一個在線的網頁服務,那用戶可能關心的是,你的系統在保證不察覺卡頓的情況下(系統的SLA, 實際可能容忍存在偶發的頁面錯誤重試)能承受多少人并發使用。
?
  • 如果你提供的是個結算系統,那用戶可能關心的是,在保證交易有效性的情況下(不能出錯,但是可以偶發超時重試,同樣是系統的SLA),每秒可以處理多少筆訂單。
舉例分析:
1? 基本算法
此處pv表意不清,實為后端日志統計的后端api的調用次數,如果有前端統計的一般意義上的pv(page visit),基本原理相同,可以簡單換算一下,pv * x-ratio = 后端調用次數。

1. ?獲取現場每日asapi PV/UV的均值/峰值。

?

2. ?取Max(PV峰值*0.8,每日PV均值)作為目標PV’, PV’時段的UV值作為實際并發用戶參考值N’, 計算PV’/perMinute/N’作為每分鐘用戶操作觸發api次數O’。

?

3. ?根據以下規則換算成后端需要支持的qps:

?
  • 3.1 ?模型假設:2/8原則——每日有80%的PV發生在20%的工作時間內(ratio=0.8
?
  • 3.2 ?假設頁面單個請求映射到后端api請求比例為1:10,假設一天working hour為8小時 (e=10)。
?
  • 3.3 ?假設一般用戶,高峰期每分鐘操作頁面10次 (o=10)。
?
  • 3.4 ?根據現場日PV計算支持N’用戶并發操作需要的qps:PV’ * ratio/(working hour?60?60?(1?ratio) )= qps

 

  • 3.5 ?根據現場峰值小時級PV計算支持N’用戶并發操作需要的qps:PV’ * ratio/(1?60?60?(1?ratio) ) = qps

4. ?根據壓測qps推算能夠支持的最大用戶同時使用數:

  • 4.1??同樣基于上述公式,根據上述假設,1分鐘內,每個用戶操作10次,每次前端操作對應后端10個api:
?
  • 1分鐘PV = N * 10 *10
  • N *10 *10 / 60 = qps ==> N = qps * 0.6
?
  • 4.2 ?如果按照小時為單位推算,1個小時內,每個用戶操作頁面100次,每次前端操作對應后端10個api:
?
  • 60分鐘PV = N * 100 *10
  • N *100 *10 / 60*60 = qps ==> N = qps * 3.6
2 ?正向推演
?
如果現場環境數據表明,高峰期9:00~10:00有50人登錄過系統,pv累計10000,那么根據(3.1),系統整體qps >= 11+ 才能維持當前用戶量正常使用。
3? 反向推演
?
如果家里環境壓測結果表明,隨機API調用qps=30, 保持上述假設,參照(4.2),即可支撐18人高峰期同時操作。
4? 不嚴謹的地方
?
上述算法針對隨機API按照1:1計算,實際上調用肯定是不均勻的,可以根據現場的數據統計下api的調用分布,壓測是模擬相同的調用分布盡量貼近實際。
另外用戶每分鐘操作頁面次數,和每次前端請求對應后端api的膨脹比都是預估出來的,雖然可以根據模型做近似,但是不如直接根據現場數據計算出來準確。
七? 其他考量
?
  • 鏈路跟蹤能力,分析瓶頸點
?
  • api log
  • eagleye-traceId
?
  • 緩存對數據庫的影響
?
  • 是否需要壓到db層,要考慮壓測場景。
  • 是否需要創造海量的隨機壓測數據 (比如針對單用戶的緩存優化場景,單一用戶的性能不能用來推送多用戶并發的場景)。
?
  • 同步接口異步接口的壓測 (staragent)
?
  • 主要考驗后臺任務處理能力(異步任務提交即時返回了)。
?
  • 系統不同層次的限流設置對API的影響
  • 比如有業務層的限流如Sentinel, Nginx層的限流如X5, 或者其他基于LVS的限流等。
  • 消息通信,尤其是廣播消息。
?
  • 數據庫,尤其是寫一致性。
?
  • 復雜場景的長鏈路調用。
?
  • Nginx/Tomcat的配置對請求的影響。
?
  • 容易忽視的對象序列化/反序列化對性能的影響。
?
  • 熱點數據。
贊(0) 打賞
關注我們
未經允許不得轉載:体育外围 » 如何做壓力測試?
分享到: 更多 (0)

評論 搶沙發

這是一種鼓勵

支付寶掃一掃打賞

微信掃一掃打賞