服務(wù)端壓測(cè)指標(biāo)如何評(píng)估？
可能很多新手QA、RD同學(xué)，對(duì)服務(wù)端壓測(cè)一直沒(méi)有系統(tǒng)的認(rèn)知，印象停留在使用壓測(cè)工具如Jmeter對(duì)單接口發(fā)壓，調(diào)整線程數(shù)和循環(huán)數(shù)來(lái)制造不同壓力，最后計(jì)算一下TPS和成功率等就完事了？網(wǎng)上雖然有不少壓測(cè)相關(guān)的文章，但多數(shù)是壓測(cè)工具的入門級(jí)使用，有的是壓測(cè)流程和指標(biāo)的簡(jiǎn)單解釋，或者就是幾個(gè)大廠牛逼的全鏈路壓測(cè)能力和壓測(cè)平臺(tái)的介紹。這些文章要不缺少系統(tǒng)性闡述，要不過(guò)于抽象不好理解，對(duì)沒(méi)怎么接觸過(guò)壓測(cè)的同學(xué)看起來(lái)還是不太理解，本文就重點(diǎn)從壓測(cè)指標(biāo)如何評(píng)估這個(gè)角度出發(fā)。
壓測(cè)流程
完整的壓測(cè)流程一般包含下面幾個(gè)步驟：
1、壓測(cè)目標(biāo)的制定
2、壓測(cè)鏈路的梳理
3、壓測(cè)環(huán)境的準(zhǔn)備
4、壓測(cè)數(shù)據(jù)的構(gòu)造
5、發(fā)壓測(cè)試
6、瓶頸定位及容量微調(diào)
7、壓測(cè)總結(jié)和報(bào)告
壓測(cè)指標(biāo)
列舉一些常用指標(biāo)，并不一定都需要關(guān)注，根據(jù)業(yè)務(wù)考慮指標(biāo)的細(xì)化粒度。
QPS：Query Per Second，每秒處理的請(qǐng)求個(gè)數(shù)
TPS：Transactions Per Second，每秒處理的事務(wù)數(shù)，TPS <= QPS
RT：Response Time，響應(yīng)時(shí)間，等價(jià)于Latency
RT分平均延時(shí)，Pct延時(shí)（Percentile分位數(shù)）。平均值不能反映服務(wù)真實(shí)響應(yīng)延時(shí)，實(shí)際壓測(cè)中一般參考Pct90，Pct99等指標(biāo)
CPU使用率：出于節(jié)點(diǎn)宕機(jī)后負(fù)載均衡的考慮，一般 CPU使用率 < 75% 比較合適
內(nèi)存使用率：內(nèi)存占用情況，一般觀察內(nèi)存是否有尖刺或泄露
Load指標(biāo)：CPU的負(fù)載，不是指CPU的使用率，而是在一段時(shí)間內(nèi)CPU正在處理以及等待CPU處理的進(jìn)程數(shù)之和的統(tǒng)計(jì)信息，表示CPU的負(fù)載情況，一般情況下 Load < CPU的核數(shù)*2，更多參考鏈接1和鏈接2
緩存命中率：多少流量能命中緩存層（redis、memcached等）
數(shù)據(jù)庫(kù)耗時(shí)：數(shù)據(jù)庫(kù)就是業(yè)務(wù)的生命，很多時(shí)候業(yè)務(wù)崩掉是因?yàn)閿?shù)據(jù)庫(kù)掛了
網(wǎng)絡(luò)帶寬：帶寬是否瓶頸
接口響應(yīng)錯(cuò)誤率 or 錯(cuò)誤日志量
這里要說(shuō)明一下QPS和TPS的區(qū)別：
QPS一般是指一臺(tái)服務(wù)器每秒能夠響應(yīng)的查詢次數(shù)，或者抽象理解成每秒能應(yīng)對(duì)多少網(wǎng)絡(luò)流量
TPS是指一個(gè)完整事務(wù)，一個(gè)事務(wù)可能包含一系列的請(qǐng)求過(guò)程。舉個(gè)??，訪問(wèn)一個(gè)網(wǎng)頁(yè)，這是一個(gè)TPS，但是訪問(wèn)一個(gè)網(wǎng)頁(yè)可能會(huì)對(duì)多個(gè)服務(wù)器發(fā)起多次請(qǐng)求，包括文本、js、圖片等，這些請(qǐng)求會(huì)當(dāng)做多次QPS計(jì)算在內(nèi)，因?yàn)樗鼈兌际橇髁啃阅軠y(cè)試中，平均值的作用是十分有限的，平均值代表前后各有50%的量，對(duì)于一個(gè)敏感的性能指標(biāo)，我們?nèi)∑骄档降滓馕吨裁矗渴亲?0%的用戶對(duì)響應(yīng)時(shí)間happy，但是50%的用戶感知到響應(yīng)延遲？還是說(shuō)50%的時(shí)間系統(tǒng)能保證穩(wěn)定，而50%的時(shí)間系統(tǒng)則是一個(gè)不可控狀態(tài)？
平均響應(yīng)時(shí)間這種指標(biāo)，只有在你每次請(qǐng)求的響應(yīng)時(shí)間都是幾乎一樣的前提下才會(huì)有一樣。再來(lái)個(gè)例子，人均財(cái)富這個(gè)概念有多沙雕相信大家也明白，19年有個(gè)很搞笑的新聞——騰訊員工平均月薪七萬(wàn)，明白平均值多不靠譜了吧??。下圖是現(xiàn)實(shí)世界中一個(gè)系統(tǒng)的響應(yīng)時(shí)間柱狀圖，RT在前20%的請(qǐng)求數(shù)較少，但是因?yàn)楹臅r(shí)特別短（拉高了均值可能是命中緩存，也可能是請(qǐng)求的快速失敗），而大多數(shù)RT是在均值之下，那才是系統(tǒng)的實(shí)際性能情況。
均值并不能反映實(shí)際情況，所以說(shuō)，我們不應(yīng)看最好的結(jié)果，相反地，應(yīng)該控制最壞的結(jié)果，用戶用得爽他不保證會(huì)傳播好口碑，但是用戶用到生氣他保證變?yōu)殒I盤俠肆意大罵，這也是為什么平均值無(wú)法帶來(lái)足夠的參考，因?yàn)閔appy的結(jié)果蒙蔽了我們的雙眼，平均值在壓測(cè)中丟失太多信息量。
總結(jié)一下，較為科學(xué)的評(píng)估方法應(yīng)該將指標(biāo)-成功率-流量三者掛鉤在一起的，比如：99%的響應(yīng)在500毫秒內(nèi)返回，其中成功率為99.99%。
根據(jù)這個(gè)方針，可以得到一些測(cè)試思路：
1、在響應(yīng)時(shí)間的限制下，系統(tǒng)最高的吞吐量（這里不對(duì)吞吐量做嚴(yán)格定義，當(dāng)成是QPS或TPS即可）
2、在成功率100%的前提下，不考慮響應(yīng)時(shí)間長(zhǎng)短，系統(tǒng)能承受的吞吐量
3、容忍一定的失敗率和慢響應(yīng)，系統(tǒng)最高能承受的吞吐量（95%成功率，前95%的請(qǐng)求響應(yīng)時(shí)間為xx毫秒時(shí)的最大QPS）
4、在上面的場(chǎng)景下還要考慮時(shí)間和資源，比如最高吞吐量持續(xù)10分鐘和持續(xù)1小時(shí)是不一樣的，不同的時(shí)間持續(xù)長(zhǎng)度下，機(jī)器資源（cpu、內(nèi)存、負(fù)載、句柄、線程數(shù)、IO、帶寬）的占用是否合理
目標(biāo)預(yù)估
壓測(cè)開展前是需要有目標(biāo)的，也就是有期望的性能情況，希望接口或系統(tǒng)能達(dá)到的性能預(yù)期，沒(méi)有目的的壓測(cè)是浪費(fèi)人力，下面給出幾種目標(biāo)預(yù)估的方法。
歷史監(jiān)控?cái)?shù)據(jù)
已經(jīng)上線并且有歷史監(jiān)控?cái)?shù)據(jù)的接口，可以查看歷史數(shù)據(jù)，找出峰值QPS和PCT99。?? 若接口A已經(jīng)上線并且做了監(jiān)控，在經(jīng)過(guò)某次大活動(dòng)或者上線時(shí)間足夠長(zhǎng)后，存量監(jiān)控?cái)?shù)據(jù)就可以使用了。
類比
新接口或者線上未監(jiān)控的接口，不存在歷史數(shù)據(jù)，但存在類似功能接口的歷史監(jiān)控?cái)?shù)據(jù)，可以通過(guò)類比得出壓測(cè)的目標(biāo)。?? 假設(shè)上一年淘寶雙十一下訂單接口QPS=x，RT=y，這一年天貓平臺(tái)整起來(lái)了，雙十一活動(dòng)與上年淘寶雙十一活動(dòng)場(chǎng)景類似，也沿用QPS=x，RT=y的目標(biāo)（例子不嚴(yán)謹(jǐn)，理解即可）。
估算
新接口或者線上未監(jiān)控的接口，不存在歷史數(shù)據(jù)，且不存在類似功能接口的數(shù)據(jù)可供參數(shù)考，此時(shí)需要估算峰值，常用方法有8/2原則——一天內(nèi)80%的請(qǐng)求會(huì)在20%的時(shí)間內(nèi)到達(dá)。
top QPS = (總PV * 0.8) / (60 * 60 * 24 * 0.2)
RT如無(wú)特殊要求，一般采用默認(rèn)值：
單服務(wù)單表類，RT<100ms
較復(fù)雜接口，RT<300ms
大數(shù)據(jù)量或調(diào)用鏈較長(zhǎng)的接口，RT<1s
??-1：電商秒殺活動(dòng)，預(yù)估同時(shí)有1000w人參與，簡(jiǎn)單起見(jiàn)假設(shè)總QPS是1000w。由于前端不同的秒殺倒計(jì)時(shí)形式使得請(qǐng)求有2s的打散，再加上nginx等webserver做了20%幾率拒絕請(qǐng)求的策略，所以下單接口總QPS = 1000w / 2 * (1 - 0.2) = 400w/s，最終壓測(cè)目標(biāo)為400w/s的QPS。
??-2：電商全天低價(jià)搶購(gòu)活動(dòng)，屠龍寶刀，點(diǎn)擊就送，一刀99級(jí)，emmmmm跑題了。根據(jù)8/2原則，預(yù)估在午休（12-1）和晚上下班后（7-10）共4h是流量高峰，估算接口峰值QPS = 活動(dòng)全天接口PV / (4*3600s)。
其他
除了前面說(shuō)到的情況，肯定還有一些我們無(wú)法下手的三無(wú)接口，無(wú)參考、無(wú)預(yù)估、無(wú)歷史數(shù)據(jù)，這時(shí)候只能一點(diǎn)一點(diǎn)來(lái)，慢慢把壓力提上去的同時(shí)收集數(shù)據(jù)，最終得出接口的最優(yōu)處理能力。
推薦閱讀：
END
長(zhǎng)按二維碼/微信掃碼 添加作者