壓測和效能分析方法論

效能測試基礎

效能測試的常見分類

• • 效能測試。用來驗證系統的效能是否滿足設計的預期，一般來說對系統的壓力會比較小，不會壓垮系統，只是進行簡單的驗證

• • 負載測試。透過不斷施加負載壓力，尋找系統最優的處理能力，最好的效能狀態，達到最大的效能指標。通常說來，負載測試的結果比效能測試的結果高一點。

• • 穩定性測試。可以認為是負載測試的一個子集，長時間不均勻的施壓，然後看系統的各項指標是否都正常。

• • 壓力測試：是我們常見的，一般我們將壓測都是指這個，用來確定系統能夠抗住的最大容量是多少，壓力測試一般都會壓到系統最大能夠承受的點，然後得出一個峰值結論。

壓測型別和施壓模式

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

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

• • 併發模式（以使用者角度來模擬使用者模式）

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

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

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

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

常用壓測工具

常用壓測工具如下：

• • wrk:

• • ab:

• • 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. 評估平均訪問量 QPS

• • 一天86400秒，一般認為請求發生在白天，即4w秒。

• • 總量除以總時間，一天算4w秒；

3. 評估高峰 QPS

• • 系統容量規劃時，不能只考慮平均 QPS，而是要抗住高峰的 QPS

• • 根據業務曲線圖來

• • 一般高峰 QPS 是平均 QPS 的 3-4 倍

4. 評估整個業務體系下各個模組、子系統的相關指標

5. 評估系統、單機極限 QPS，評估需要多少機器

• • 進行壓測和資料分析

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

做好分析總結

要做好分析總結，比如：

• • 這個系統上線後，真能抗的住麼 ? 除了有壓測的資料，還要有自己有預估。自己的系統，哪些方面可能存在瓶頸, 會導致上線後出問題的? 系統上線前要有充分準備和整體評估/預估。

• • 系統上線後，萬一扛不住怎麼解決？是否有限流方案？是否有降級方案？

• • 系統現在 10w 使用者是什麼情況? 那麼假如 1000w使用者的情況, 是不是線性增長呢?需要做些什麼考慮呢？

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

一些具體 case 的壓測方法

測試資料準備

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

儲存層（資料庫和快取）的壓測方法

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

• • 首先針對單機進行壓測

• • 然後再去分析，叢集的整體抗量能力，需要注意，叢集能夠承載的量不是單機的累加值，一般在叢集中每增加一臺機器，可以採用 80% 遞減的方式來粗略評估。

• • 最後需要注意，叢集的整體抗量能力需要根據實際情況去達到一個合理的配置，並不是叢集中的機器越多越好。壓到一個符合預期的值即可。