体育外围
壓測的一般流程和方法是什么？需要關注哪些數據指標？如何推算后端需要支持的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的配置對請求的影響。
- 容易忽視的對象序列化/反序列化對性能的影響。
- 熱點數據。
