《如何做好性能壓測》系列專題分享的第四期，該專題將從性能壓測的設計、實現、執行、監控、問題定位和分析、應用場景等多個緯度對性能壓測的全過程進行拆解，以幫助大家構建完整的性能壓測的理論體系，並提供有例可依的實戰。
該系列專題分享由阿里巴巴 PTS 團隊出品，歡迎在文末處加入性能壓測交流群，參與該系列的線上分享。
第一期：《壓測環境的設計和搭建》，點擊這里。
第二期：《性能壓測工具選型對比》，點擊這里。
第三期：《阿里巴巴在開源壓測工具 JMeter 上的實踐和優化》，點擊這里。
第四期：《並發模式與 RPS 模式之爭，性能壓測領域的星球大戰》
性能測試的常見分類
負載測試：
一種驗證性測試，它的目的是驗證預設負載條件下的性能表現是否達到性能目標（可用性、並發數/RPS、響應時間等），在達到性能目標之后不會繼續增加負載。
穩定性測試：
負載測試的一個子集，側重於發現、驗證只有經過長時間的運行才會暴露的問題。比如內存泄漏、FGC 等。
壓力測試：
一種破壞性測試，嘗試探測應用或者基礎設施的極限能力。因此壓力測試過程中會一直增加負載直到部分性能指標不再符合性能預期。壓力測試能發現僅在高負載條件下出現的同步問題、競爭條件、內存泄漏等。通過壓力測試我們還可以確定應用服務在什么條件下會變得不可用，不可用的現象，以及可以通過哪些監控指標來監控即將發生的不可用，壓測結果通常可以為限流等管控系統提供數據支撐。
容量測試：
往往與容量規划一起進行，是在保證用戶體驗不受影響（穩定性）的前提下，使有限的資源的利用率最大化（成本）。也可以用它來預估未來用戶量增長到某個量級的情況下，需要多少資源（例如處理器、內存、磁盤、網絡帶寬）來支持。
業務場景建模
一般情況下，在性能測試中模擬每個用戶可能的操作場景基本上是不可能實現的，我們必須要關注的性能場景包括但不限於：
- 高頻使用的場景
- 關鍵的業務場景
- 最耗性能的場景
- 曾經出現過問題的場景
- ...............
在測試具有大量新功能的業務時，往往需要與業務方一起確認預期內有哪些功能點可能會被高頻使用，需要與研發人員確認哪些功能雖然使用頻率不高，但是存在性能隱患、容易引起雪崩效應；在測試已經上線的功能時，還可以通過業務監控、系統日志來分析現有用戶的行為模式，得到更加逼近真實用戶行為的業務場景。
業務場景的操作路徑：
業務場景的操作路徑可以借助一些可視化的工具來描述，這部分工作相對比較簡單，不再詳細深入。我們詳細說明一下比較常見的延時策略。
思考時間：思考時間模擬的是用戶在等待響應、閱讀頁面內容、表單填寫等延遲操作的場景。每個人的閱讀速度、輸入速度都存在非常大的差異，決定了每個人的思考時間也是不一樣的，在性能測試配置中有常見的四種延時模型覆蓋了絕大部分的延時場景：
- 固定時間：顧名思義，設置一個固定的思考時間。
- 均勻分布：均勻分布在范圍的上限和下限之間的隨機數。
- 正態分布：根據中心極限定理，如果一個事物受到多種因素的影響，不管每個因素本身是什么分布，它們加總后，結果的平均值就是正態分布。
- 負指數分布：該模型將延遲時間的頻率強烈地偏向該范圍的一端。
- 雙駝峰正態分布：雙峰駝正態分布可以模擬第一次訪問時把頁面說明整個仔細的閱讀一遍，但下次訪問時直接掃過頁面，點擊頁面深處的操作鏈接。
我們通常可以通過以下方式對思考時間進行建模：
- 如果是已上線系統，可以從線上日志統計分析出來平均值以及標准方差
- 沒有線上日志，可以從內部人員的使用模式中收集響應的數據
- 可以計算自己和同事訪問的時候，在不同頁面停留的時間
- 如果沒有更好的來源，也可以從第三方統計數據獲取延時數據
確認監控指標
在性能測試執行過程中，往往需要實時觀察各項指標是否正常，包括客戶端指標、應用服務器、數據庫、中間件、網絡入口等各方面的指標。更重要的是，監控的過程是發現系統瓶頸的過程，監控數據是性能基線管理、容量規划甚至是高可用架構的重要基礎。我們通常需要關注的監控指標包括：
- 業務接口指標，響應時間、RPS、成功率等；
- 網絡指標，數據吞吐量、數據錯誤率等；
- 服務器指標，連接數、CPU、內存、I/O、磁盤等；
- ……
最理想的狀態是，這些監控指標能夠與性能測試工具集成，在一個操作界面上展示各個維度的監控數據，並能夠基於策略來智能化、自動化識別指標異常。這對快速、准確的定位壓測過程中可能出現的各種問題是至關重要的。
原文鏈接：https://mp.weixin.qq.com/s/k6MRiK0UE9tawxwZm3SMMw