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

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

(相關資料圖)

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

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

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

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

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

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

常用壓測工具

常用壓測工具如下：

wrk: https://github.com/wg/wrkab: https://httpd.apache.org/docs/2.4/programs/ab.htmlwebbench性能指標常見性能指標業(yè)務指標：并發(fā)數(shù)、吞吐量、響應時間并發(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 這樣的指標來衡量。吞吐量還有平均吞吐量、峰值吞吐量、最低吞吐量之分。響應時間：一次事務的處理時間。通常指從一個請求發(fā)出，到服務器進行處理后返回，再到接收完畢應答數(shù)據(jù)的時間間隔。一般有平均響應時間、P95、P99 之分。

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

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

他們之間的關系是：

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

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

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

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

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

壓測觀察指標

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

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

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

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

我們分析系統(tǒng)性能問題，需要找準要點，這就要求我們的壓測報告要確實有效，是要非常嚴謹?shù)?，條理清晰， 要一步一步分析出瓶頸，而且要明白為啥到了瓶頸，然后怎么優(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)資源，或者外部接口導致了性能問題。

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

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

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

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

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

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

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

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

做好容量預估

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

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

1.得到業(yè)務指標，評估總訪問量詢問產(chǎn)品、運營得到一些 uv、pv等指標2.評估平均訪問量 QPS一天86400秒，一般認為請求發(fā)生在白天，即4w秒?？偭砍钥倳r間，一天算4w秒；3.評估高峰 QPS系統(tǒng)容量規(guī)劃時，不能只考慮平均 QPS，而是要抗住高峰的 QPS根據(jù)業(yè)務曲線圖來一般高峰 QPS 是平均 QPS 的 3-4 倍4.評估整個業(yè)務體系下各個模塊、子系統(tǒng)的相關指標5.評估系統(tǒng)、單機極限 QPS，評估需要多少機器進行壓測和數(shù)據(jù)分析6.適當冗余度，對壓測得到的結(jié)果，我們實際上線后要做點冗余，避免線上實際壓力太大導致無法快速擴容做好分析總結(jié)

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

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

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

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

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

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

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

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

關鍵詞： 響應時間 性能測試 系統(tǒng)資源 測試數(shù)據(jù) 性能指標