壓測(cè)和性能分析方法論

性能測(cè)試基礎(chǔ)

性能測(cè)試的常見分類

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

壓測(cè)類型和施壓模式

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

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

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

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

RPS 模式（以請(qǐng)求的吞吐量角度來模擬吞吐模式）

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

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

常用壓測(cè)工具

常用壓測(cè)工具如下：

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

性能指標(biāo)

常見性能指標(biāo)

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

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

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

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

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

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

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

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

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

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

壓測(cè)觀察指標(biāo)

不管是哪種壓測(cè)類型，壓測(cè)要觀察的指標(biāo)一般需要包括：

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

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

生成嚴(yán)謹(jǐn)?shù)膲簻y(cè)報(bào)告

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

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

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

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

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

•  分別知道單機(jī)和集群能夠承載的性能和拐點(diǎn)

單臺(tái)機(jī)器的最大 QPS 是多少？

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

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

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

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

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

做好容量預(yù)估

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

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

1. 1. 得到業(yè)務(wù)指標(biāo)，評(píng)估總訪問量

• 詢問產(chǎn)品、運(yùn)營(yíng)得到一些 uv、pv等指標(biāo)

2. 2. 評(píng)估平均訪問量 QPS

• 一天86400秒，一般認(rèn)為請(qǐng)求發(fā)生在白天，即4w秒。
• 總量除以總時(shí)間，一天算4w秒；

3. 3. 評(píng)估高峰 QPS

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

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

• 進(jìn)行壓測(cè)和數(shù)據(jù)分析

6. 6. 適當(dāng)冗余度，對(duì)壓測(cè)得到的結(jié)果，我們實(shí)際上線后要做點(diǎn)冗余，避免線上實(shí)際壓力太大導(dǎo)致無法快速擴(kuò)容

做好分析總結(jié)

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

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

一些具體 case 的壓測(cè)方法

測(cè)試數(shù)據(jù)準(zhǔn)備

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

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

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

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

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

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