本文始發自部落格：[**服務端壓測怎麼做**](https://zingpho y.github.io/2020/04/26/%E6%9C%8D%E5%8A%A1%E7%AB%AF%E5%8E%8B%E6%B5%8B%E6%80%8E%E4%B9%88%E5%81%9A/) 博文的內容並不都是我原創的，行文思路來源於一次內部分享，再結合網上眾多參考資料總結出來的，算是一個學習筆記。 可能很多QA、RD同學跟我都一樣，對服務端壓測一直沒有系統的認知，印象停留在使用壓測工具如Jmeter對單介面發壓，調整執行緒數和迴圈數來製造不同壓力，最後計算一下TPS和成功率等就完事了？網上雖然有不少壓測相關的文章，但多數是壓測工具的入門級使用，有的是壓測流程和指標的簡單解釋，或者就是幾個大廠牛逼的全鏈路壓測能力和壓測平臺的介紹。這些文章要不缺少系統性闡述，要不過於抽象不好理解，對沒怎麼接觸過壓測的同學不太友好。  本文嘗試在QA角度梳理一次完整的壓測過程，嘗試總結更為普適的壓測思路，給大家提供更有意義的參考。 --- ## 壓測背景 測試分很多種，網上很多文章[^1]會玩弄概念，搬出來3個名詞：壓力測試（Stress Testing）、效能測試（Performance Testing）、負載測試（Load Testing）。一般情況下並不需要做這麼細粒度的概念區分，這3個概念我覺得是沒辦法完整區分各自邊界的，至少在程式邏輯上難以做得到，更多差異只是來自於不同的壓測策略，所以儘管忽略這幾個概念的區別，都叫它壓測或者效能測試即可。 ### 為什麼需要壓測 拿技術人熟知的阿里舉例，應該是國內做壓測最好的一個大廠。外界熟知的阿里2012雙11活動，2012年11月11日零點，阿里各種系統報錯、立刻下單報錯、購物車支付報錯、支付系統報錯、購物車的東西丟失，系統顯示交易成功率不到50%，產生了大量超賣，給阿里帶來很大的損失。那一年的雙11後，庫存、商品、退款和相應資料庫的同學，為了處理超賣導致的問題，沒日沒夜加了兩週的班，同時給了使用者不少糟糕購物體驗。 為什麼出現這麼嚴重的問題？因為對整個全交易鏈路上的各個子系統的承受能力不清楚，並且錯誤預估了可能會達到的流量，也沒有完善的預案，兵敗如山倒。 2013年阿里首次提出了全鏈路壓測方案：一方面可讓鏈路的各個系統知道自己的承壓極限；另一方面可讓各個系統有個明確的優化目標，瞭解到整個鏈路的瓶頸並評估資源情況。 ### 單系統壓測與全鏈路壓測 為什麼只做單系統壓測還不夠呢？ 在活動開始的瞬間，各系統都面臨自身服務的巨大的壓力，而系統之間是有互相依賴關係的，單機壓測沒有考慮到依賴環節壓力都比較大的情況。一個系統出現故障，故障會在鏈路流轉過程中層層累加，會造成無法評估的影響。 所以最可靠的方式是完全模擬真實場景來壓測，通過線上全鏈路壓測提前發現問題。 ### 壓測流程 完整的壓測流程一般包含下面幾個步驟，引用自[文末參考資料](https://developer.aliyun.com/article/721643)： 1. 壓測目標的制定 2. 壓測鏈路的梳理 3. 壓測環境的準備 4. 壓測資料的構造 5. 發壓測試 6. 瓶頸定位及容量微調 7. 壓測總結  --- ## 壓測目標 ### 壓測作用 * 新服務，無預估目標，需要通過壓測得到服務基準資料或找到系統瓶頸進行優化 * 有明確的壓測目標，需要通過壓測確定服務的各項指標是否達標 * 常態化壓測，為後期效能優化指導方向或提供參考依據 ### 壓測指標 列舉一些常用指標，並不一定都需要關注，根據業務考慮指標的細化粒度。 * QPS：Query Per Second，每秒處理的請求個數 * TPS：Transactions Per Second，每秒處理的事務數，TPS <= QPS * RT： Response Time，響應時間，等價於Latency RT分平均延時，Pct延時（Percentile分位數）。平均值不能反映服務真實響應延時，實際壓測中一般參考Pct90，Pct99等指標 * CPU使用率：出於節點宕機後負載均衡的考慮，一般 CPU使用率 < 75% 比較合適 * 記憶體使用率：記憶體佔用情況，一般觀察記憶體是否有尖刺或洩露 * Load指標：CPU的負載，不是指CPU的使用率，而是在一段時間內CPU正在處理以及等待CPU處理的程序數之和的統計資訊，表示CPU的負載情況，一般情況下 Load < CPU的核數*2，更多參考[連結1](https://www.ruanyifeng.com/blog/2011/07/linux_load_average_explained.html)和[連結2](https://www.jianshu.com/p/02825a66e46f) * 快取命中率：多少流量能命中快取層（redis、memcached等） * 資料庫耗時：資料庫就是業務的生命，很多時候業務崩掉是因為資料庫掛了 * 網路頻寬：頻寬是否瓶頸 * 介面響應錯誤率 or 錯誤日誌量 這裡要說明一下QPS和TPS的區別： * QPS一般是指一臺伺服器每秒能夠響應的查詢次數，或者抽象理解成每秒能應對多少網路流量 * TPS是指一個完整事務，一個事務可能包含一系列的請求過程。舉個