壓測的一般流程和方法是什么?需要關注哪些數據指標?如何推算后端需要支持的qps?本文分享總結壓測過程中需要注意的問題,希望對同學們有所啟發,歡迎討論。
- 后端
- 單api
- 單業務邏輯場景
- 前端
- 單request
- 單操作
- 單頁
- 整體頁面平均情況
- qps
- rt
- 成功率
- 頁面平均響應時間 (重要)。
- 并發量(其實沒那么重要,主要還是qps)。
- 最大用戶同時在線數 (用戶登錄系統,一般不需要額外壓測,除非業務場景特殊)。
- 網絡質量(延遲,波動等,不展開)。
- cpu usage
- load
- mem
- jvm/fullGC
- 連接數(netstat)
- disk io (iostat / iotop)
- 如果你提供的是一個在線的網頁服務,那用戶可能關心的是,你的系統在保證不察覺卡頓的情況下(系統的SLA, 實際可能容忍存在偶發的頁面錯誤重試)能承受多少人并發使用。
- 如果你提供的是個結算系統,那用戶可能關心的是,在保證交易有效性的情況下(不能出錯,但是可以偶發超時重試,同樣是系統的SLA),每秒可以處理多少筆訂單。
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
- 鏈路跟蹤能力,分析瓶頸點
- api log
- eagleye-traceId
- 緩存對數據庫的影響
- 是否需要壓到db層,要考慮壓測場景。
- 是否需要創造海量的隨機壓測數據 (比如針對單用戶的緩存優化場景,單一用戶的性能不能用來推送多用戶并發的場景)。
- 同步接口異步接口的壓測 (staragent)
- 主要考驗后臺任務處理能力(異步任務提交即時返回了)。
- 系統不同層次的限流設置對API的影響
- 比如有業務層的限流如Sentinel, Nginx層的限流如X5, 或者其他基于LVS的限流等。
- 消息通信,尤其是廣播消息。
- 數據庫,尤其是寫一致性。
- 復雜場景的長鏈路調用。
- Nginx/Tomcat的配置對請求的影響。
- 容易忽視的對象序列化/反序列化對性能的影響。
- 熱點數據。