談談壓測

狼爺發表於2020-05-24

背景

隨著業務不斷髮展，使用者量不斷增加，系統負載越來越高。為了解決系統負載問題，我們是不是直接大量增加機器就可以了？
同時，公司業務開展需要，可能需要開展各種營銷活動，目前系統是否能夠支援那麼多使用者也是個未知數，如何解決呢？
答案就是今天要講的壓測。

目的

  • 驗證單個業務及整個的處理能力及響應時間等
  • 驗證系統的效能瓶頸
  • 合理的容量規劃，而不是大量增加

分類

  • 單介面壓測
  • 全鏈路壓測

效能測試指標

業務類

  • 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公司提供的一款效能測試工具，通過模擬成千上萬個使用者實施併發操作，測試系統的效能，並且提供詳細的測試結果分析，協助使用者查詢問題。
    收費應用。
  • 自研工具

參考資料

相關文章