壓測和性能分析方法論

性能測試基礎

性能測試的常見分類

• 性能測試。用來驗證系統的性能是否滿足設計的預期，一般來說對系統的壓力會比較小，不會壓垮系統，只是進行簡單的驗證
• 負載測試。通過不斷施加負載壓力，尋找系統最優的處理能力，最好的性能狀態，達到最大的性能指標。通常說來，負載測試的結果比性能測試的結果高一點。
• 穩定性測試。可以認為是負載測試的一個子集，長時間不均勻的施壓，然后看系統的各項指標是否都正常。
• 壓力測試：是我們常見的，一般我們將壓測都是指這個，用來確定系統能夠抗住的最大容量是多少，壓力測試一般都會壓到系統最大能夠承受的點，然后得出一個峰值結論。

壓測類型和施壓模式

壓測類型一般分為單服務壓測和全鏈路壓測兩種壓測類型。

而我們常見的施壓模式有以下兩種:

• 并發模式（以用戶角度來模擬用戶模式）

并發是指并發用戶數，從業務角度來模擬同時在線的用戶數，從而達到預期的并發量，要計算吞吐的話還需要做個轉換。但是在某些場景比較符合場景的預期

RPS 模式（以請求的吞吐量角度來模擬吞吐模式）

• RPS（Requests Per Second）是指每秒請求數。RPS 模式即“吞吐量模式”，通過設置每秒發出的請求數，從服務端的角度出發，直接衡量系統的吞吐能力，免去并發到 RPS 的繁瑣轉化，一步到位。

并發模式與 RPS 模式沒有優劣，各自有各自適用的場景。

常用壓測工具

常用壓測工具如下：

• wrk: https://github.com/wg/wrk
• ab: https://httpd.apache.org/docs/2.4/programs/ab.html
• webbench

性能指標

常見性能指標

業務指標：并發數、吞吐量、響應時間

•  并發數。是指系統同時處理的請求數，對于互聯網系統而言，一般就是指同時訪問系統的用戶數。
•  吞吐量(QPS 的最大值)：是指單位時間內系統處理請求的數量，體現的是系統的處理能力。我們一般用 TPS、 QPS 這樣的指標來衡量。吞吐量還有平均吞吐量、峰值吞吐量、最低吞吐量之分。
• 響應時間：一次事務的處理時間。通常指從一個請求發出，到服務器進行處理后返回，再到接收完畢應答數據的時間間隔。一般有平均響應時間、P95、P99 之分。

響應時間和吞吐量要達到一個平衡點，隨著吞吐量的增加，響應時間會先維持一個點，然后會開始迅速加大，隨之而來的是吞吐量也很難上去了。我們對響應時間是有要求的，因此我們不能只追求吞吐量，一定是在一個合理的響應時間內找到最大的吞吐量。

響應時間一定是在成功率的基礎上的， 如果出現失敗，那么這個響應時間是無效的。成功率一般要 100%。

他們之間的關系是：

QPS（TPS）= 并發數 / 平均響應時間  
吞吐量理論值 = 并發數 / 平均響應時間
并發數 = QPS*平均響應時間

系統資源：CPU空閑率、內存使用、網絡IO、磁盤讀寫量、句柄數等

性能計數器，指的是服務器或者操作系統性能的一些指標數據，包括系統負載 System Load、對象和線程數、內存使用、CPU 使用、磁盤和網絡 I/O 使用等指標。這些指標是系統監控的重要參數，反映系統負載和處理能力的一些關鍵指標，通常這些指標和性能是強相關的。這些指標很高，成為瓶頸，通常也預示著性能可能會出現問題。

最優的方式是采用百分比

參考 平均值是不靠譜的，最為正確的統計做法是用百分比分布統計 一文，最佳實踐經驗是采用百分比。比如 Top Percentile（TP）指標 ，TP50的意思是指 50%的請求都小于某個值，TP90表示90%的請求小于某個時間。

壓測觀察指標

不管是哪種壓測類型，壓測要觀察的指標一般需要包括：

• 成功率、失敗率
• 系統資源（CPU、內存、帶寬、IO）
• 響應時間，平均響應時間、P95/P99響應時間，一定要關注 P95 和 P99，不能只看平均時間，P99 時間可以較好的去判別線上用戶的時間體驗
• 吞吐量(QPS/TPS)

一個基本的壓測數據示例如下：

生成嚴謹的壓測報告

我們分析系統性能問題，需要找準要點，這就要求我們的壓測報告要確實有效，是要非常嚴謹的，條理清晰， 要一步一步分析出瓶頸，而且要明白為啥到了瓶頸，然后怎么優化？因此就要求我們要輸出嚴謹的壓測報告。這里有一些經驗：

• 壓測的時候，要找到一個性能拐點；如果壓力一上來就達到瓶頸了，那么還需要往回調一點，直到找到一個最佳的性能拐點。系統性能是一個拋物線形態，到達性能峰值后繼續施壓會導致性能下降，因此我們壓測最重要的就是找到那個最佳的性能拐點。因此整個施壓過程逐步施壓，到達性能峰值后繼續施壓，如果繼續施壓后性能不升反降就說明到了拐點了
• 如何分析性能瓶頸，找到 QPS 提升不上去的原因呢?

QPS 不會一直上升，到某個點后就會持平甚至下降，出現性能拐點，此時就需要開始分析原因。

具體的方式就是，先抓沒有到極限的 profile 情況(cpu,block,io,內存)，再抓剛好到極限的，最后抓已經超過極限的，然后分析這幾種情況下，到底是哪個系統資源，或者外部接口導致了性能問題。

如果是某個組件或者外部服務是性能瓶頸點，那么還需要進一步分析下，是不是組件的使用姿勢不對？是不是沒處理好連接數？不能說一找到某個組件的問題就結束了，還需要進一步更深層的審視下。

•  分別知道單機和集群能夠承載的性能和拐點

單臺機器的最大 QPS 是多少？

平行擴展后的 QPS 又是多少，是線性增長么?（肯定不會線性增長, 到某個程度后相關資源一定都會出現瓶頸，關鍵是要找到對應的瓶頸點）

• 系統資源如何分析，舉個 CPU 的例子

首先看 CPU，如果 CPU 沒有跑滿，則說明不是 CPU 的問題，就不用關心CPU，然后就要其他的資源如 io, swap, 內存, 網卡等

如果有多個 CPU 核心, 則觀察每個核心的 cpu 的使用情況，不能光看整體的 CPU 使用率

如果 CPU 跑滿了，那么抓 CPU 的 profile, 觀測看看哪個調用比較耗時.

做好容量預估

系統上線前就必須要能夠有預估/評估大概, 再通過壓測驗證, 了解每個細節,包括資源, 依賴關系, 部署情況, 機房分布, 降級策略, 容災方案, 備用方案

容量預估是大型系統上線的必備品，因為只有合理的進行容量預估，才能更好的去根據系統要承載的量級去設計我們的系統，容量規劃需要盡量做到以最少的機器抗住更多的流量；規劃 ok 了之后，我們需要用一些性能壓測手段來驗證是否符合預期。有了合理的容量規劃和評估之后，上線之前去壓測系統的時候才能知道我們需要壓到什么程度，然后，容量預估并不是拍腦袋的，容量評估需要考慮如下幾點：

1. 1. 得到業務指標，評估總訪問量

• 詢問產品、運營得到一些 uv、pv等指標

2. 2. 評估平均訪問量 QPS

• 一天86400秒，一般認為請求發生在白天，即4w秒。
• 總量除以總時間，一天算4w秒；

3. 3. 評估高峰 QPS

• 系統容量規劃時，不能只考慮平均 QPS，而是要抗住高峰的 QPS
• 根據業務曲線圖來
• 一般高峰 QPS 是平均 QPS 的 3-4 倍

4. 4. 評估整個業務體系下各個模塊、子系統的相關指標
5. 5. 評估系統、單機極限 QPS，評估需要多少機器

• 進行壓測和數據分析

6. 6. 適當冗余度，對壓測得到的結果，我們實際上線后要做點冗余，避免線上實際壓力太大導致無法快速擴容

做好分析總結

要做好分析總結，比如：

• 這個系統上線后，真能抗的住么 ? 除了有壓測的數據，還要有自己有預估。自己的系統，哪些方面可能存在瓶頸, 會導致上線后出問題的? 系統上線前要有充分準備和整體評估/預估。
• 系統上線后，萬一扛不住怎么解決？是否有限流方案？是否有降級方案？
• 系統現在 10w 用戶是什么情況? 那么假如 1000w用戶的情況, 是不是線性增長呢?需要做些什么考慮呢？
• 系統上線前就必須要能夠有預估/評估大概, 再通過壓測驗證, 了解每個細節,包括資源, 依賴關系, 部署情況, 機房分布, 降級策略, 容災方案, 備用方案

一些具體 case 的壓測方法

測試數據準備

高質量的測試數據應當能真實的反映用戶的使用場景，我們一般會選擇以線上真實數據作為數據源，經過采樣、過濾、脫敏，作為性能測試的測試數據。但是在拿真實數據測試之前，必須要先線下模擬測試數據，至少先驗證整個系統的基本性能需求后才能拿真實數據做性能測試。

存儲層（數據庫和緩存）的壓測方法

針對無狀態服務的話，要提高并發能力很容易，可以無腦擴容。但是針對有狀態的存儲系統，它能支持的最大并發數不是可以無限擴展的，因此我們一定要能夠清楚我們的數據存儲層能抗多少量，而針對這種存儲集群的壓測，一般就是：

• 首先針對單機進行壓測
• 然后再去分析，集群的整體抗量能力，需要注意，集群能夠承載的量不是單機的累加值，一般在集群中每增加一臺機器，可以采用 80% 遞減的方式來粗略評估。
• 最后需要注意，集群的整體抗量能力需要根據實際情況去達到一個合理的配置，并不是集群中的機器越多越好。壓到一個符合預期的值即可。

文轉載自微信公眾號「 后端系統和架構」，作者「 AllenWu」，可以通過以下二維碼關注。

轉載本文請聯系「后端系統和架構」公眾號。