壓測流程

一、效能場景分析與建立

• 壓測場景

  • 業務峰值穩定性：大促業務等峰值業務穩定性考驗
  • 新系統上線：準確探知站點能力，防止系統一上線即被使用者流量打垮
  • 技術升級驗證：大的技術架構升級後進行效能評估，驗證新技術場景的站點效能狀態
  • 容量規劃：對站點進行精細化的熔鍊規劃，為系統擴容，效能最佳化提供資料參考，節省成本投入，提高資源利用率
  • 效能探測：探測系統中的效能瓶頸點，進行針對性最佳化

• 壓測策略（方法）

  • 負載測試：系統在不同負載下的效能表現，發現系統效能的拐點，從而找出系統最佳效能
    
  • 壓力測試：評估系統處於或超過瓶頸時，系統的執行狀況，關注點在於系統峰值負載或超出最大載荷情況下的處理能力，同時需要關注負載減小後，系統的恢復能力
    
  • 基準測試：透過基準測試建立一個已知的效能水平（稱為基準線），當系統的軟硬體發生變化後再進行一次基準測試，確定變化對效能的影響
  • 配置測試：不斷調整系統軟硬體各種配置，使得系統效能達到最優
  • 穩定性測試：在特定的負載（略高於正常負載）下，持續施壓，驗證系統能否長期穩定執行

• 系統架構梳理（分析潛在風險點）
  技術架構，分層機構，模組劃分，資料庫、快取、訊息佇列等中介軟體的使用
  

• 壓什麼？

  • 關鍵業務的介面：根據業務確定
  • 訪問量的的介面：可以找開發提供介面訪問排行榜，前20-30個

• 壓測方案編寫

  • 背景和目的
  • 業務和技術指標
  • 涉及範圍和鏈路：需要和相關的團隊一一對其
  • 壓測實施里程碑：每輪壓測的目標和要做的事情
  • 壓測任務及進度：整體的壓測任務拆分以及當前進度，提前評估風險
  • 壓測模型和策略：類似於功能測試過程中的用例評審，查漏補缺的過程

二、壓測指令碼編寫及除錯

• 編寫
  一定要寫響應斷言

• 除錯

  • 檢視結果樹
  • 除錯取樣器
  • JMeter日誌
  • 用表格檢視結果
  • charles或fiddler

三、指令碼執行

• JMeter單機壓測
  Jmeter是純Java應用，對CPU和記憶體的消耗較大。在大量併發情況下，容易發生CPU和記憶體溢位的問題。因此，建議單臺機器的執行緒數不要超過500個，以保持較好的效能和穩定性‌。
• JMeter分散式壓測
  
• 空介面壓測

四、指標監控

• 業務指標：如併發使用者數、TPS（系統每秒處理事務數）、成功率、響應時間
• 硬體指標：如CPU、記憶體、磁碟、網路I/O的使用率
• 軟體指標：執行緒池、JDBC連線池、JVM（GC/FULL GC/堆大小）、慢SQL、等待/死鎖、快取命中

五、定位瓶頸

• 確保壓測流量完全打到服務

  • 網路層頻寬
  • ip地址限流
  • slb自動伸縮失敗
  • Nginx負載均衡失敗/Nginx機器效能受限
  • 限流熔斷降級
  • 施壓機器效能瓶頸

• 如果是某個硬體指標的問題，需要深入分析

  • CPU高: 使用top檢視佔用資源最高的程序、根具PID查詢佔用最高的執行緒，如果是java可以用jstack檢視執行緒正在執行的堆疊
  • 記憶體高：檢視哪個程序佔用記憶體多，以及是否有大量的虛擬記憶體交換（swap）
  • 磁碟I/O高：透過減少日誌輸出、非同步
  • 網路I/O：檢視傳輸內容大小，可以透過壓縮傳輸內容、在本地設定快取、分多次傳輸等降低網路的壓力

• 如果是中介軟體的問題，需要深入分析

  • 執行緒池不夠：增加執行緒，並弄清楚為什麼執行緒阻塞
  • JDBC連線池：增加連線數，並弄清楚連線未釋放的原因

• 如果是資料庫的問題----80%
  檢視慢sql，所引命中率，鎖等

• 如果上述指標正常可以考慮快取、邏輯、演算法等的問題

六、效能調優

• 效能調優後必須進行功能迴歸測試
• 快取
• 非同步
• 預先處理
  • web標準提供了至少兩種提前載入方式：preload、prefetch
  • 預載入
• 時空轉換
  • 時間換空間：資料放到磁碟、需要時再讀取
  • 空間換時間：資料放到記憶體、cdn

七、輸出測試報告