BigHead、Peki等 逆熵研習(xí)社

服務(wù)端性能測(cè)試是針對(duì)服務(wù)端驗(yàn)證性能狀況以及是否存在問題進(jìn)行的測(cè)試栏豺，執(zhí)行過(guò)程包括目標(biāo)制定（確定需求）蚌讼、測(cè)試準(zhǔn)備缚窿、測(cè)試執(zhí)行、測(cè)試結(jié)果分析等環(huán)節(jié)肃叶。除測(cè)試執(zhí)行外其他環(huán)節(jié)也非常重要夯辖，精深的細(xì)節(jié)在后續(xù)專項(xiàng)中一一討論蕴茴，本文重點(diǎn)討論下這個(gè)大過(guò)程每個(gè)階段的目標(biāo)以及要點(diǎn)劝评。

確定性能測(cè)試目標(biāo)

需求確認(rèn)

明確目標(biāo)或者需求是首要的事情，它關(guān)乎后面整個(gè)測(cè)試的準(zhǔn)備與執(zhí)行倦淀。以下是常見的目標(biāo)

*衡量全系統(tǒng)的負(fù)載能力蒋畜，評(píng)估下可以正常服務(wù)的負(fù)載范圍。

*某個(gè)服務(wù)的極限壓力撞叽，瓶頸點(diǎn)等姻成。

*某個(gè)服務(wù)升級(jí)后性能是否變得糟糕插龄。

還有些情況針對(duì)業(yè)務(wù)中的某些場(chǎng)景需要確認(rèn)下性能狀況的，比如用戶登錄科展，業(yè)務(wù)查詢均牢，電商的高并發(fā)交易等場(chǎng)景等。不管是上面概括性的描述還是具體場(chǎng)景的描述潛在的和目標(biāo)相關(guān)的三個(gè)要素需要我們把它抽象出來(lái)：

1.在什么樣的系統(tǒng)范圍內(nèi)進(jìn)行驗(yàn)證才睹，需要弄明白目標(biāo)所指的被測(cè)系統(tǒng)范圍——是整個(gè)業(yè)務(wù)系統(tǒng)還是業(yè)務(wù)系統(tǒng)的某一部分徘跪？

2.需要驗(yàn)證業(yè)務(wù)場(chǎng)景，根據(jù)這個(gè)業(yè)務(wù)場(chǎng)景我們需要找到用戶可能發(fā)送的請(qǐng)求的集合琅攘。

3.需要達(dá)到的狀態(tài)垮庐，是用戶的并發(fā)狀態(tài)，還是服務(wù)的極限壓力狀態(tài)等坞琴，這個(gè)是我們后面達(dá)到目標(biāo)的一個(gè)關(guān)鍵標(biāo)準(zhǔn)哨查。

在確定目標(biāo)時(shí)還需要我們確定該目標(biāo)是否合理，也就是能否滿足最終的業(yè)務(wù)需求剧辐。舉例子來(lái)說(shuō)解恰，如果業(yè)務(wù)重要目標(biāo)是TPS在3萬(wàn)情況下服務(wù)正常，那目標(biāo)就不能定為：驗(yàn)證系統(tǒng)的極限壓力為3萬(wàn)浙于，因?yàn)榧词瓜到y(tǒng)極限壓力達(dá)到了3萬(wàn)用戶的體驗(yàn)絕對(duì)算不上是正常的。

最后在整個(gè)性能測(cè)試的過(guò)程中需要我們要經(jīng)承矗回顧下我們的取舍和方案是否能夠滿足最初的目標(biāo)羞酗。

指標(biāo)確定

確定了目標(biāo)后，接下來(lái)要做的事情是將目標(biāo)轉(zhuǎn)化為性能測(cè)試本身驗(yàn)證的指標(biāo)紊服。這些指標(biāo)即包含代表用戶端體驗(yàn)的請(qǐng)求指標(biāo)檀轨，也包含系統(tǒng)后端服務(wù)狀態(tài)。下面給出了我們經(jīng)常見到的指標(biāo)：

系統(tǒng)容量：系統(tǒng)最大能容納多少用戶的操作? 通常業(yè)務(wù)系統(tǒng)的用戶操作有多個(gè)流程欺嗤，可以按照一定比例進(jìn)行折算測(cè)試参萄。

并發(fā)數(shù)：模擬并發(fā)用戶數(shù)，一個(gè)系統(tǒng)中應(yīng)該有不同的操作的并發(fā)數(shù)組合煎饼，盡可能模擬用戶真實(shí)場(chǎng)景讹挎。響應(yīng)時(shí)間：接口/用戶操作的響應(yīng)時(shí)間，如果時(shí)間比較長(zhǎng)會(huì)影響用戶體驗(yàn)吆玖，增大系統(tǒng)負(fù)載筒溃。

吞吐率：系統(tǒng)每秒處理的事務(wù)數(shù)量（TPS），和這個(gè)指標(biāo)相關(guān)的指標(biāo)是每秒鐘處理的請(qǐng)求數(shù)（QPS）沾乘。這兩者是什么關(guān)系呢怜奖？處理用戶請(qǐng)求的事務(wù)包含一個(gè)或者多個(gè)請(qǐng)求，舉個(gè)例子說(shuō)用戶通過(guò)驗(yàn)證碼登陸這個(gè)事務(wù)就包含了用戶獲取驗(yàn)證碼請(qǐng)求和用戶發(fā)送登陸請(qǐng)求兩個(gè)請(qǐng)求（如果每秒能夠滿足20個(gè)人同時(shí)登陸翅阵，那么對(duì)應(yīng)的TPS就是20）歪玲。明白了這個(gè)邏輯我們就可以根據(jù)具體的場(chǎng)景測(cè)試出對(duì)應(yīng)的吞吐量數(shù)據(jù)迁央。

系統(tǒng)性能指標(biāo)：服務(wù)器CPU，內(nèi)存滥崩，IO岖圈，帶寬使用情況等，這些指標(biāo)是服務(wù)狀態(tài)的重要指示夭委。

測(cè)試準(zhǔn)備

準(zhǔn)備測(cè)試計(jì)劃

確定了系統(tǒng)目標(biāo)和指標(biāo)幅狮，接下來(lái)還有一個(gè)事情就是需要準(zhǔn)備下測(cè)試計(jì)劃。計(jì)劃是將最終目標(biāo)分解成每步可以完成的子目標(biāo)株灸，例如下面的計(jì)劃：

其中對(duì)于對(duì)于用戶獲取驗(yàn)證碼登陸這個(gè)場(chǎng)景包含如下請(qǐng)求：

在測(cè)試開始前對(duì)具體的性能表現(xiàn)尚不十分清楚崇摄，所以測(cè)試計(jì)劃體現(xiàn)主要測(cè)試路徑即可，具體的壓力計(jì)劃可以根據(jù)測(cè)試中具體表現(xiàn)進(jìn)行調(diào)整慌烧。

準(zhǔn)備測(cè)試環(huán)境

測(cè)試環(huán)境的建設(shè)一般來(lái)講比較復(fù)雜逐抑，需要根據(jù)具體業(yè)務(wù)場(chǎng)景和公司資源來(lái)選擇，比如可以利用生產(chǎn)環(huán)境進(jìn)行性能測(cè)試（需要考慮安全和后期的數(shù)據(jù)清理）屹蚊，也可使用線下環(huán)境測(cè)試厕氨，一般會(huì)盡可能選擇和線上硬件資源比較類似的機(jī)器，便于對(duì)比分析汹粤。線下性能測(cè)試安全性會(huì)比較高命斧，但有一定額外成本。

性能測(cè)試環(huán)境在建設(shè)過(guò)程中除去需要考慮業(yè)務(wù)本身的拓?fù)渫膺€有技術(shù)性要素要考慮嘱兼，例如數(shù)據(jù)庫(kù)国葬、緩存和隊(duì)列如何模擬類似線上的狀況。如果是做升級(jí)前后性能對(duì)比類測(cè)試性能環(huán)境只需做到類似線上部署即可芹壕，但要高度模擬線上的狀況汇四，需要考慮一下因素

1.硬件環(huán)境，除機(jī)器狀況需要考慮外踢涌，網(wǎng)絡(luò)狀況等也需要重點(diǎn)考慮通孽。

2.軟件版本一致，包括操作系統(tǒng)睁壁、數(shù)據(jù)庫(kù)背苦、中間件以及被測(cè)系統(tǒng)等。

3.配置與線上一致潘明，包括系統(tǒng)糠惫、中間件以及服務(wù)配置。

4.場(chǎng)景一致钉疫，數(shù)據(jù)硼讽、請(qǐng)求分布以及量級(jí)與線上一致（對(duì)于敏感數(shù)據(jù)可以通過(guò)脫敏處理）。

此外牲阁，性能測(cè)試環(huán)境中又一個(gè)非常頭疼的問題是第三方以來(lái)服務(wù)的問題固阁，使用線上第三方做壓測(cè)大多數(shù)情況下是不允許的壤躲，因此做一個(gè)第三方性能MOCK是一個(gè)常用的方案，在這種方案中第三方請(qǐng)求的響應(yīng)時(shí)間分布需要作為可配置項(xiàng)精心管理备燃。

壓測(cè)工具準(zhǔn)備

性能測(cè)試工具非常多碉克，比如ab，jmeter并齐，loadrunner等漏麦，需要注意的是服務(wù)端性能測(cè)試的重點(diǎn)是測(cè)試設(shè)計(jì)，準(zhǔn)備况褪，以及后期的性能瓶頸分析上撕贞，絕不是掌握一個(gè)工具使用就是性能測(cè)試專家了。在壓測(cè)工具選擇上理論上保證能夠快速達(dá)到預(yù)期的并發(fā)規(guī)模且壓測(cè)工具本身不成為性能瓶頸即可测垛。以下三種性能工具可以作為選擇的參考：

Apache JMeter

優(yōu)點(diǎn)：圖形化捏膨，操作簡(jiǎn)單，帶有cookie信息的請(qǐng)求食侮，保存配置文件号涯，功能強(qiáng)大。

缺點(diǎn)：擴(kuò)展起來(lái)稍微復(fù)雜了些锯七。

Http_Load

優(yōu)點(diǎn)：并行復(fù)用的方式運(yùn)行链快，可以以一個(gè)單一的進(jìn)程運(yùn)行，一般不會(huì)把客戶機(jī)搞死眉尸。

缺點(diǎn)：測(cè)試結(jié)果分析有限域蜗，平臺(tái)依賴linux。

Multi-Mechanize

優(yōu)點(diǎn)：自定義腳本效五，可實(shí)現(xiàn)參數(shù)加密，結(jié)果呈現(xiàn)形式好

缺點(diǎn)：只能做負(fù)載測(cè)試炉峰，結(jié)果處理效率很低（測(cè)試1個(gè)小時(shí)畏妖，出結(jié)果就得半小時(shí)，數(shù)據(jù)生成圖像時(shí)間較長(zhǎng)）

其中Apache JMeter在日常測(cè)試中營(yíng)運(yùn)非常廣泛疼阔，是一個(gè)專門為運(yùn)行和服務(wù)器裝載測(cè)試而設(shè)計(jì)的戒劫、100％的純Java桌面運(yùn)行程序。初期它是為Web/HTTP測(cè)試而設(shè)計(jì)的婆廊，但是它已經(jīng)擴(kuò)展以支持各種各樣的測(cè)試模塊迅细。它和用于HTTP和SQL數(shù)據(jù)庫(kù)（使用JDBC）的模塊一起運(yùn)送。它可以用來(lái)測(cè)試靜止資料庫(kù)或者活動(dòng)資料庫(kù)中的服務(wù)器的運(yùn)行情況淘邻，可以用來(lái)模擬對(duì)服務(wù)器或者網(wǎng)絡(luò)系統(tǒng)加以重負(fù)荷以測(cè)試它的抵抗力茵典，或者用來(lái)分析不同負(fù)荷類型下的所有運(yùn)行情況。它也提供了一個(gè)可替換的界面用來(lái)定制數(shù)據(jù)顯示宾舅，測(cè)試同步及測(cè)試的創(chuàng)建和執(zhí)行统阿。

使用步驟：

此外彩倚，如果是在阿里云上部署服務(wù)，阿里云配套的PTS在測(cè)試計(jì)劃管理和測(cè)試執(zhí)行以及測(cè)試結(jié)果報(bào)告上都是非常優(yōu)良的扶平。

測(cè)試執(zhí)行

測(cè)試開始執(zhí)行后首選需要做的一個(gè)事情是驗(yàn)證下測(cè)試環(huán)境帆离，原因比較簡(jiǎn)單——由于測(cè)試環(huán)境本身復(fù)雜性比較高，未經(jīng)驗(yàn)證直接進(jìn)行性能測(cè)試很難保證環(huán)境本身是不誤的结澄。環(huán)境驗(yàn)證的原則是先驗(yàn)證少量事務(wù)哥谷，再進(jìn)行小壓力的確認(rèn)，最后確保環(huán)境沒問題后再開始后面的按照測(cè)試計(jì)劃進(jìn)行測(cè)試麻献。

接下來(lái)順理成章的是執(zhí)行測(cè)試并記錄結(jié)果们妥。這個(gè)階段除了按照計(jì)劃記錄響應(yīng)結(jié)果和機(jī)器指標(biāo)外，服務(wù)端的日志也需要關(guān)注赎瑰，至少在每個(gè)場(chǎng)景結(jié)束時(shí)確認(rèn)下是否有錯(cuò)誤日志王悍。

一般服務(wù)系統(tǒng)的響應(yīng)隨虛擬用戶數(shù)（VU）的增長(zhǎng)變化如下圖所示，其中0～a之間是性能表現(xiàn)良好的區(qū)域餐曼，一般線上性能表現(xiàn)的期望預(yù)期在這段范圍內(nèi)压储，所以常規(guī)的性能測(cè)試在這段范圍內(nèi)進(jìn)行即可。a~b區(qū)間隨著并發(fā)數(shù)提升TPS升高已經(jīng)處于非線性區(qū)域源譬，但對(duì)用戶來(lái)說(shuō)請(qǐng)求延遲并不是十分明顯集惋，這段區(qū)間作為負(fù)載測(cè)試區(qū)間。對(duì)應(yīng)線上來(lái)說(shuō)這塊兒區(qū)域很少達(dá)到踩娘，在極少數(shù)高峰達(dá)到這段區(qū)域時(shí)系統(tǒng)尚能正常運(yùn)行刮刑。b~d區(qū)域請(qǐng)求延遲已經(jīng)明顯升高，甚至TPS也開始下降养渴，這段區(qū)間是壓力測(cè)試的區(qū)間雷绢，僅測(cè)試系統(tǒng)崩潰點(diǎn)、極限吞吐等情況下具有實(shí)際意義理卑。在實(shí)際測(cè)試中要根據(jù)響應(yīng)狀況及時(shí)調(diào)整并發(fā)數(shù)量以按照最初設(shè)計(jì)的目標(biāo)進(jìn)行翘紊。

報(bào)告整理與問題分析

測(cè)試過(guò)程按照預(yù)期和實(shí)際的表現(xiàn)執(zhí)行結(jié)束后，系統(tǒng)的性能狀況數(shù)據(jù)已經(jīng)基本上拿到藐唠。對(duì)于滿足預(yù)期的性能測(cè)試到此只要按照?qǐng)鼍耙约安l(fā)狀況整理出指標(biāo)結(jié)果便可完成本次任務(wù)帆疟。但對(duì)于不能滿足預(yù)期的需要投入更多的精力進(jìn)行分析。對(duì)于簡(jiǎn)單包含很少模塊的系統(tǒng)進(jìn)行瓶頸相對(duì)比較簡(jiǎn)單宇立，通過(guò)臨時(shí)添加性能日志便可定位出問題所在踪宠。但對(duì)于復(fù)雜系統(tǒng)時(shí)該如何呢，例如下面這個(gè)系統(tǒng)當(dāng)出現(xiàn)性能問題時(shí)該如何定位呢妈嘹？有幾個(gè)思路可以供大家參考：

*按照標(biāo)準(zhǔn)添加規(guī)范的性能日志柳琢，通過(guò)性能日志可以將問題定位某個(gè)服務(wù)便可降低一個(gè)個(gè)查找的成本。

*通過(guò)trace技術(shù)查找調(diào)用鏈條耗時(shí)較長(zhǎng)的部分，進(jìn)而分析問題所在染厅。

*如果以上兩個(gè)都沒有可以考慮將復(fù)雜系統(tǒng)拆分成小的子系統(tǒng)進(jìn)行驗(yàn)證測(cè)試痘绎，通過(guò)訛化與排除確定問題所在。

性能測(cè)試還有非常多的內(nèi)容值得我們深入探討肖粮，今天我們從流程上先討論這么多孤页，更多深入有意思的事情留待我們一一深入探索。