談談壓測
背景
隨著業務不斷發展，用戶量不斷增加，系統負載越來越高。為了解決系統負載問題，我們是不是直接大量增加機器就可以了？
同時，公司業務開展需要，可能需要開展各種營銷活動，目前系統是否能夠支援那麼多用戶也是個未知數，如何解決呢？
答案就是今天要講的壓測。
目的
- 驗證單個業務及整個的處理能力及響應時間等
- 驗證系統的性能瓶頸
- 合理的容量規劃，而不是大量增加
分類
- 單介面壓測
- 全鏈路壓測
性能測試指標
業務類
- TPS
- 相應時間
– 平均響應時間、最小響應時間、最大響應時間、90%響應時間等
– 百分位數是一個統計學名詞。99% 的百分位響應時間，指的是 99% 的請求響應時間都處在這個值以下。
– 如果99%響應時間跟平均響應時間相差很大，那麼說明是抗不住這麼大量的，需要做相應調整及優化 - 業務成功率
– 壓測前要確定壓測的業務成功率，不能把報錯的數據當做壓測結果，一般可以定業務成功率最少為1% - 系統資源指標
- CPU使用率
- 記憶體使用率
- 磁碟繁忙率
- 網路IO
全鏈路壓測
目的
只做單系統壓測是不夠的，因為在活動開始的瞬間，各系統都面臨自身服務的巨大的壓力，而系統之間是有互相依賴關係的，單機壓測沒有考慮到依賴環節壓力都比較大的情況。一個系統出現故障，故障會在鏈路流轉過程中層層累加，會造成無法評估的影響。
為什麼選擇線上環境做全鏈路壓測
通常情況下公司不可能按照線上環境架構與性能要求1比1的搭建一套離線環境
應用TPS
由於是全鏈路壓測，所以不能單看一個介面的TPS，需要查看同個應用的不同介面，相同應用不同介面的TPS之和可以當做是應用總的TPS
準備工作
- 確定壓測場景
– 制定大促的壓測場景（比如秒殺、抽獎等）
– 確認壓測鏈路 - 估算流量漏斗
– 流量轉化不是百分百的，如100個用戶看到商詳，可能會有50個人會去下單，最後有45個人進行了支付，那麼在全鏈路壓測的時候就要進行流量漏斗的估算。
– 可以根據近7天線上真實用戶的行為數據分型分析建模，以及往期同類型活動線上的流量分布情況進行估算 - 確定壓測目標
- 壓測腳本
- 發通知及公告
– 通知商家避開壓測時間段
– 通知相關業務方關注相關告警等 - 限流
– 可能線上有開啟限流，壓測的時候要適當放開 - 影子庫
– 做業務數據隔離，防止生成臟數據影響線上業務 - 外部mock伺服器
– mock掉部分服務，比如微信支付
工具
- ab
ab是apache自帶的壓力測試工具。ab非常實用，它不僅可以對apache伺服器進行網站訪問壓力測試，也可以對或其它類型的伺服器進行壓力測試。比如nginx、tomcat、IIS等。 - wrk
wrk 是一款c語言開發的現代的http性能基準測試工具，使用簡單，功能強大。 - JMeter
Apache JMeter是一款純java編寫負載功能測試和性能測試開源工具軟體，小巧輕便且免費。 - Loadrunner
Loadrunner是HP公司提供的一款性能測試工具，通過模擬成千上萬個用戶實施並發操作，測試系統的性能，並且提供詳細的測試結果分析，協助用戶查找問題。
收費應用。 - 自研工具
參考資料
- 服務端壓測怎麼做 //zingphoy.github.io/2020/04/26/服務端壓測怎麼做/
- 阿里巴巴的全鏈路壓測 //my.oschina.net/cctester/blog/994727
- 有贊全鏈路壓測方案設計與實施詳解 //mp.weixin.qq.com/s/0a-Sd_fCkE2mDFzNpKxf7A
