壓測和性能分析方法論

性能測試基礎(chǔ)

性能測試的常見分類

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

壓測類型和施壓模式

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

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

• 并發(fā)模式（以用戶角度來模擬用戶模式）

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

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

• RPS（Requests Per Second）是指每秒請求數(shù)。RPS 模式即“吞吐量模式”，通過設(shè)置每秒發(fā)出的請求數(shù)，從服務(wù)端的角度出發(fā)，直接衡量系統(tǒng)的吞吐能力，免去并發(fā)到 RPS 的繁瑣轉(zhuǎn)化，一步到位。

并發(fā)模式與 RPS 模式?jīng)]有優(yōu)劣，各自有各自適用的場景。

常用壓測工具

常用壓測工具如下：

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

性能指標

常見性能指標

業(yè)務(wù)指標：并發(fā)數(shù)、吞吐量、響應(yīng)時間

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

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

響應(yīng)時間一定是在成功率的基礎(chǔ)上的， 如果出現(xiàn)失敗，那么這個響應(yīng)時間是無效的。成功率一般要 100%。

他們之間的關(guān)系是：

QPS（TPS）= 并發(fā)數(shù) / 平均響應(yīng)時間  
吞吐量理論值 = 并發(fā)數(shù) / 平均響應(yīng)時間
并發(fā)數(shù) = QPS*平均響應(yīng)時間

系統(tǒng)資源：CPU空閑率、內(nèi)存使用、網(wǎng)絡(luò)IO、磁盤讀寫量、句柄數(shù)等

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

最優(yōu)的方式是采用百分比

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

壓測觀察指標

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

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

一個基本的壓測數(shù)據(jù)示例如下：

生成嚴謹?shù)膲簻y報告

我們分析系統(tǒng)性能問題，需要找準要點，這就要求我們的壓測報告要確實有效，是要非常嚴謹?shù)模瑮l理清晰， 要一步一步分析出瓶頸，而且要明白為啥到了瓶頸，然后怎么優(yōu)化？因此就要求我們要輸出嚴謹?shù)膲簻y報告。這里有一些經(jīng)驗：

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

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

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

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

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

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

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

• 系統(tǒng)資源如何分析，舉個 CPU 的例子

首先看 CPU，如果 CPU 沒有跑滿，則說明不是 CPU 的問題，就不用關(guān)心CPU，然后就要其他的資源如 io, swap, 內(nèi)存, 網(wǎng)卡等

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

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

做好容量預估

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

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

1. 1. 得到業(yè)務(wù)指標，評估總訪問量

• 詢問產(chǎn)品、運營得到一些 uv、pv等指標

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

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

3. 3. 評估高峰 QPS

• 系統(tǒng)容量規(guī)劃時，不能只考慮平均 QPS，而是要抗住高峰的 QPS
• 根據(jù)業(yè)務(wù)曲線圖來
• 一般高峰 QPS 是平均 QPS 的 3-4 倍

4. 4. 評估整個業(yè)務(wù)體系下各個模塊、子系統(tǒng)的相關(guān)指標
5. 5. 評估系統(tǒng)、單機極限 QPS，評估需要多少機器

• 進行壓測和數(shù)據(jù)分析

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

做好分析總結(jié)

要做好分析總結(jié)，比如：

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

一些具體 case 的壓測方法

測試數(shù)據(jù)準備

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

存儲層（數(shù)據(jù)庫和緩存）的壓測方法

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

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

文轉(zhuǎn)載自微信公眾號「 后端系統(tǒng)和架構(gòu)」，作者「 AllenWu」，可以通過以下二維碼關(guān)注。

轉(zhuǎn)載本文請聯(lián)系「后端系統(tǒng)和架構(gòu)」公眾號。