作者 | 冬恒
來源 | 阿裡技術公衆号
一 壓測目标
在開始做壓測計劃之前，一定要先明确壓測的目标是什麼，雖然最終的目标肯定都是優化系統的性能，但是不同的出發點，可能需要采取不同的方法。
一般來說，可能有以下一些目的：
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 = 後端調用次數。
- 擷取現場每日asapi PV/UV的均值/峰值。
- 取Max（PV峰值*0.8，每日PV均值）作為目标PV'， PV'時段的UV值作為實際并發使用者參考值N'， 計算PV'/perMinute/N'作為每分鐘使用者操作觸發api次數O'。
- 根據以下規則換算成後端需要支援的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
- 根據壓測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 / 6060 = 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的配置對請求的影響。
- 容易忽視的對象序列化/反序列化對性能的影響。
- 熱點資料。