1. 需求分析與性能測試的整體設(shè)計1.1 為什么性能測試必須先咬透需求很多人一上來就打開壓測工具先把接口地址填進去再說。我見過太多這種場景最后測出來的結(jié)果除了給自己看根本沒法說服任何人。性能測試的第一步從來不是搭腳本而是把需求文檔翻爛把每個指標摳清楚。做性能測試的真正目的不是“測出一個TPS數(shù)字”而是回答三個問題系統(tǒng)現(xiàn)在能扛多少、瓶頸在哪里、距離目標還差多少。這三個問題都繞不開需求分析。拿最常見的電商下單流程舉例。業(yè)務方說“系統(tǒng)至少要支持一萬用戶同時在線”這句話看起來很簡單但如果不拆解你根本不知道該拿什么去壓。一萬用戶同時在線不代表一萬用戶同時下單。真實場景可能只有百分之幾的人在下單大部分人在瀏覽。真正需要關(guān)注的并發(fā)下單量可能只有幾百遠沒有想象中那么大。需求分析階段必須跟產(chǎn)品、開發(fā)、運維反復對齊的核心點包括業(yè)務量級日活、峰值在線、核心操作頻次這些數(shù)字從哪來是否經(jīng)過業(yè)務側(cè)確認時間分布是否存在明顯的波峰波谷比如電商大促、節(jié)假日搶購、月底結(jié)算操作比例讀操作和寫操作的比例瀏覽、搜索、提交訂單分別占多少數(shù)據(jù)規(guī)模數(shù)據(jù)庫里存量數(shù)據(jù)多少壓測時用多少因為數(shù)據(jù)量級直接影響查詢性能網(wǎng)絡環(huán)境用戶是走內(nèi)網(wǎng)還是公網(wǎng)移動端占比多少有沒有弱網(wǎng)場景要求這些信息如果需求文檔里沒有就主動去找產(chǎn)品和對口同事確認。問一次不清楚就問兩次千萬不要自己想當然。我踩過最大的坑之一就是按照自己的猜測去定指標結(jié)果壓測報告出來以后業(yè)務方根本不認說這不是他們的真實場景最后整個測試周期被拉長了一倍。1.2 指標定級與目標值的確定邏輯需求對齊之后就要把指標目標值定下來。這一步做不好后面所有工作都白搭。性能指標一般分為三類對應的標準完全不同核心指標如下單成功率、支付成功率這類指標不達標就是事故必須嚴格卡住關(guān)鍵指標如響應時間、吞吐量直接影響用戶體驗需要按業(yè)務場景分級設(shè)定參考指標如服務器CPU使用率、數(shù)據(jù)庫連接數(shù)主要用于定位瓶頸輔助判斷目標值的確定不能拍腦袋。最穩(wěn)妥的方式是看歷史數(shù)據(jù)如果系統(tǒng)已經(jīng)上線過一段時間線上監(jiān)控里積累的指標數(shù)據(jù)就是最好的基準。比如線上TPS日常在500左右大促時沖到2000那么壓測目標就可以定為正常情況1.5倍峰值情況按2到2.5倍去壓。沒有歷史數(shù)據(jù)的新系統(tǒng)可以按業(yè)務預估量推算。這里給一個常用的簡化計算方法假設(shè)預估日訂單量是10萬筆核心高峰期集中在2小時內(nèi)則平均TPS 100000 / (2 × 3600) ≈ 13.9。再考慮峰值系數(shù)至少2倍目標TPS可以定為28到30左右。如果是秒殺或搶購類場景峰值系數(shù)要到5到10倍那就是70到140的TPS。這里要特別注意TPS目標不是一個人拍腦袋定的最終一定要以評審的形式跟各方確認。把計算過程、數(shù)據(jù)來源、假設(shè)條件都寫清楚讓大家在評審會上確認簽字后面即便出了問題你也有依據(jù)可查。這是保護自己也是讓測試工作更專業(yè)的方式。1.3 場景建模從業(yè)務鏈路到壓測模型需求分析完成后最關(guān)鍵的一步就是把真實業(yè)務轉(zhuǎn)化為可執(zhí)行的壓測場景。這一步直接決定了壓測結(jié)果能不能代表生產(chǎn)環(huán)境表現(xiàn)。場景建模的核心有兩個業(yè)務模型和請求模型。業(yè)務模型是什么樣的就是搞清楚一段完整業(yè)務流程里每個操作步驟的占比和順序。拿下單場景來說真實用戶的行為路徑是瀏覽商品、搜索、加入購物車、確認訂單、提交訂單、支付。每一步都有響應時間、成功率和并發(fā)量也都有各自的調(diào)用鏈和資源消耗。如果把壓力全部打在提交訂單一個接口上測出來的結(jié)果跟真實情況差之千里。在做業(yè)務建模時我常用的一種方法是把業(yè)務操作按“頻率×資源消耗”劃分成三類類型特點典型操作壓測占比高頻低耗調(diào)用頻繁、單個消耗小瀏覽、搜索、查看詳情60%-70%中頻中耗頻率適中、消耗中等添加購物車、確認訂單20%-30%低頻高耗頻率低、資源消耗大提交訂單、支付回調(diào)5%-10%請求模型則是把業(yè)務模型翻譯成壓測腳本。這里必須考慮到具體參數(shù)怎么構(gòu)造。比如用戶ID不能全用同一個否則數(shù)據(jù)庫索引、緩存命中率都會被污染結(jié)果失真商品庫存數(shù)據(jù)要顧及扣減邏輯和超賣問題訂單號要有唯一性約束否則數(shù)據(jù)庫主鍵沖突導致報錯。一個容易忽略的痛點是壓測過程中的參數(shù)化相關(guān)性處理。比如下單成功后會生成一個訂單ID這個ID要傳給支付接口使用。很多人寫腳本的時候只盯著下單接口沒有做實時的參數(shù)傳遞和關(guān)聯(lián)提取導致壓測到支付階段時不斷報錯還以為是系統(tǒng)問題。這一類問題在場景建模時就要提前設(shè)計好關(guān)聯(lián)規(guī)則而不是等腳本跑不通了再修。1.4 測試環(huán)境與數(shù)據(jù)準備決定結(jié)果可信度的地基場景模型定好之后接下來要做的是環(huán)境準備和數(shù)據(jù)準備。這個環(huán)節(jié)看著瑣碎實際上是決定性能測試結(jié)果可信度的關(guān)鍵。首先明確一個原則性能測試環(huán)境盡可能貼近生產(chǎn)環(huán)境。但這種貼近不是絕對等價。生產(chǎn)環(huán)境的機器配置、網(wǎng)絡拓撲、中間件版本、數(shù)據(jù)庫數(shù)據(jù)量這些都應該盡量一致因為CPU核數(shù)不同、內(nèi)存不同、帶寬不同都會直接影響性能指標。能做成跟生產(chǎn)1:1鏡像當然最好但在很多公司里這是不現(xiàn)實的這時候就必須做好“等比縮放”的規(guī)劃并且把縮放關(guān)系在報告里寫清楚。比如生產(chǎn)環(huán)境是4臺應用服務器壓測環(huán)境只能給2臺那你測出來的結(jié)果要按這個差異進行說明不能直接拿壓測環(huán)境的絕對TPS去對標生產(chǎn)目標。數(shù)據(jù)準備這一塊是很多人翻車的地方。壓測的數(shù)據(jù)量如果遠小于生產(chǎn)環(huán)境數(shù)據(jù)庫的SQL執(zhí)行計劃就會不一樣。生產(chǎn)環(huán)境千萬級數(shù)據(jù)的表查詢走的是索引而你壓測環(huán)境只有十萬條數(shù)據(jù)優(yōu)化器可能直接走全表掃描查出來的響應時間快得離譜。這個結(jié)果不但不具有參考性反而會誤導判斷。數(shù)據(jù)準備至少要做到幾點核心表的數(shù)據(jù)量級與生產(chǎn)一致尤其是訂單表、用戶表、庫存表這些熱點表數(shù)據(jù)分布要均勻比如用戶ID不要連續(xù)集中在某段區(qū)間避免數(shù)據(jù)庫頁緩存命中率虛高造數(shù)要覆蓋邊界情況比如庫存為零的商品、超時未支付的訂單、狀態(tài)異常的記錄壓測產(chǎn)生的臟數(shù)據(jù)要清理否則多輪壓測的數(shù)據(jù)會互相干擾有些公司為了省事直接用生產(chǎn)環(huán)境備份的數(shù)據(jù)脫敏后灌入壓測環(huán)境這是很好的做法。如果做不到就需要自己寫數(shù)據(jù)生成腳本或者用開源的數(shù)據(jù)構(gòu)造工具但無論如何都不能用少量數(shù)據(jù)硬湊。我在早期做測試時就曾經(jīng)因為數(shù)據(jù)量不足測出來的下單接口平均響應時間只有50毫秒結(jié)果上了生產(chǎn)之后實際響應時間要300毫秒被業(yè)務方直接質(zhì)疑測試專業(yè)性。后來把數(shù)據(jù)量補齊之后才真正找到了問題所在。2. 壓測工具選型與腳本開發(fā)的核心細節(jié)2.1 工具選型開源的夠用商業(yè)的看需要壓測工具的選擇會直接影響整個測試效率和結(jié)果的可信度。工具不在多在于合適。我用過的工具不算少從早期的開源工具到商業(yè)方案都有接觸各自適用場景差別很大。開源工具里JMeter是我最常用的選擇。主要原因是它幾乎覆蓋了所有我能想到的協(xié)議場景HTTP、HTTPS、WebService、JDBC、JMS、TCP甚至Dubbo這類RPC協(xié)議也能通過自定義插件支持。社區(qū)生態(tài)很成熟遇到問題搜一下基本都有答案。對于絕大多數(shù)公司來說JMeter加上配套的監(jiān)控插件已經(jīng)能支撐80%以上的性能測試場景。Locust的高并發(fā)模擬能力和Python腳本編寫方式在某些場景下非常順手但它的斷言和報告能力相對輕量。Gatling的Scala DSL寫起來優(yōu)雅性能表現(xiàn)和報告也很漂亮但學習門檻高一些。商業(yè)工具像LoadRunner和NeoLoad功能強大從網(wǎng)絡協(xié)議層面能做到更精細的模擬但價格不低。我個人的建議是團隊里至少有一位熟練使用JMeter的成員。因為開源性讓你沒有授權(quán)限制社區(qū)也足夠強大遇到問題不必等待廠商支持。如果公司預算充足也可以通過商業(yè)工具獲取更強的網(wǎng)絡級模擬和專業(yè)支持。但無論選哪種都要基于實際場景模型來選擇量級大、場景復雜的用功能強的簡單校驗型的用輕量的即可不要過度設(shè)計。2.2 腳本開發(fā)的規(guī)范與要點不是能跑就行腳本開發(fā)是很多人忽視但實際非常重要的環(huán)節(jié)。因為腳本質(zhì)量直接影響測試結(jié)果的真實度而很多問題恰恰藏在腳本里。腳本開發(fā)必須遵循的幾個原則我逐一展開。第一參數(shù)化一定要做徹底。常用的參數(shù)包括用戶ID、商品ID、訂單號、手機號這些參數(shù)如果寫死壓測根本測不出真實效果。拿用戶ID來說如果幾百個并發(fā)全部用同一個用戶ID則數(shù)據(jù)庫連接池的會話可能被復用緩存也會集中命中同一份數(shù)據(jù)導致響應時間虛低。參數(shù)化方式有很多CSV文件、數(shù)據(jù)庫讀取、函數(shù)生成均可但根據(jù)業(yè)務規(guī)則選擇適當?shù)姆绞讲灰还赡X全用隨機函數(shù)。第二關(guān)聯(lián)關(guān)系必須處理好。業(yè)務鏈路中存在大量上下游依賴前面接口返回的訂單ID、Token、交易流水號要能自動化提取并傳給后續(xù)接口。這個做不好壓測跑到后面全是報錯根本壓不到真實業(yè)務邏輯。第三斷言要合理。壓測腳本中如果不加斷言接口返回500也算成功那TPS再高也沒意義。但斷言也不能過度復雜否則會消耗額外資源。通常的做法是校驗Http狀態(tài)碼為200同時校驗核心業(yè)務字段比如返回碼為0、或包含成功標識。既不過度也不缺失。第四腳本的“思考時間”要精心設(shè)計。真實用戶從“瀏覽商品”到“點擊下單”之間是有間隔的這個間隔就是思考時間。完全沒有思考時間的壓測是極限壓力測試不是業(yè)務真實性測試兩者目標完全不同。在做容量評估和容量規(guī)劃時往往需要的是結(jié)合思考時間的混合場景模型極限壓測一般用于評估系統(tǒng)底線。我自己在腳本開發(fā)中都會做一層規(guī)范化封裝。通用函數(shù)提取到公共模塊參數(shù)文件統(tǒng)一管理腳本結(jié)構(gòu)按業(yè)務模塊分層。前期可能覺得這是多余功夫但一旦壓測場景多起來規(guī)范的腳本維護成本遠低于一鍋粥式的腳本。2.3 執(zhí)行策略壓測節(jié)奏不是一把梭腳本準備好之后真正進入到壓測執(zhí)行階段節(jié)奏控制尤為關(guān)鍵。壓測執(zhí)行要分階段走不要上來就全量并發(fā)猛打。道理很簡單就像人跑馬拉松要先熱身再加速直接沖刺會導致數(shù)據(jù)失真也容易給系統(tǒng)造成短暫沖擊把故障誤判為容量不足。我常用的執(zhí)行策略是分層加壓單接口基準測試先對單個接口單線程持續(xù)壓測摸清基礎(chǔ)響應時間和成功率這一步通常跑5分鐘單接口梯度加壓從50并發(fā)開始逐步加100、200、400、800每個梯度保持一段時間觀察各項指標變化趨勢混合場景壓測按業(yè)務模型比例同時壓測多個接口模擬真實用戶行為鏈路穩(wěn)定性測試在70%目標負載下持續(xù)運行至少30分鐘觀察是否存在內(nèi)存泄漏、連接池耗盡等問題峰值與突發(fā)測試模擬瞬時流量沖擊比如秒殺場景下的5分鐘集中請求每一階段之間要保留觀察窗口讓系統(tǒng)恢復穩(wěn)定狀態(tài)再進入下一輪。切忌一個場景跑完馬上跑下一個中間不清理數(shù)據(jù)、不檢查系統(tǒng)狀態(tài)那樣得到的指標是混在一起的很難定位問題。執(zhí)行過程中監(jiān)控是同時進行的不只是看壓測端的TPS和響應時間還要同步看服務端指標CPU、內(nèi)存、磁盤I/O、網(wǎng)絡帶寬、GC頻率、數(shù)據(jù)庫連接池狀態(tài)、慢查詢數(shù)。壓測端數(shù)據(jù)和服務端數(shù)據(jù)只有放在一起看才能形成完整證據(jù)鏈。舉個例子如果TPS上不去但壓測端響應時間不斷增加同時數(shù)據(jù)庫慢查詢也在增長那問題大概率在SQL或者索引層面而不在應用服務器。2.4 全鏈路壓測與容量規(guī)劃的一些經(jīng)驗近些年的趨勢是做全鏈路壓測也就是從網(wǎng)關(guān)到應用、到中間件、再到數(shù)據(jù)庫整個鏈路全部納入壓測范圍。這種方式的優(yōu)勢是能發(fā)現(xiàn)在模塊層面聯(lián)調(diào)時才暴露的問題比如某些環(huán)節(jié)的超時配置不一致、連接池大小不匹配。但全鏈路壓測對環(huán)境和數(shù)據(jù)隔離的要求非常高。壓測流量如果不加區(qū)分地打入生產(chǎn)環(huán)境會造成臟數(shù)據(jù)落地。常見的做法是在請求入口打上壓測標識業(yè)務代碼在一些關(guān)鍵環(huán)節(jié)識別到標識后會走獨立的影子庫或影子表壓測數(shù)據(jù)不污染真實業(yè)務數(shù)據(jù)。在容量規(guī)劃方面我對團隊的建議是至少保存三輪有效壓測數(shù)據(jù)再做趨勢評估。第一輪是基線第二輪是優(yōu)化后對比第三輪是小幅加壓的邊際效應分析。不同輪次的測試結(jié)果要放到同一個維度下比較比如都統(tǒng)一在相同并發(fā)數(shù)、相同數(shù)據(jù)量下做否則數(shù)據(jù)之間沒有可比性容量規(guī)劃也就無從談起。3. 性能問題定位與調(diào)優(yōu)的完整路徑3.1 瓶頸分析的正確打開方式壓測做完之后真正的重頭戲才剛開始。壓測結(jié)果不理想是常態(tài)可關(guān)鍵是你得能從一堆數(shù)據(jù)指標里揪出真正的瓶頸所在。這環(huán)節(jié)極其考驗打印經(jīng)驗也是最容易走彎路的地方。我的習慣方法是自上而下逐層排查。先看應用層再往下看中間件最后看數(shù)據(jù)庫和操作系統(tǒng)。為什么這樣排因為性能問題的表象通常出現(xiàn)在上層比如用戶側(cè)響應慢但根因往往在下層比如數(shù)據(jù)庫索引失效或者連接池阻塞。如果一上來就去翻數(shù)據(jù)庫慢查詢而忽略了應用線程阻塞的問題就會白白浪費大量時間。應用層的排查重點是線程狀態(tài)和GC情況。用線程Dump看是否有大量線程處于BLOCKED或WAITING狀態(tài)用GC日志看GC頻率和停頓時間。如果一次性Full GC的停頓時間超過幾百毫秒接口響應自然會變慢TPS也會受到明顯影響。中間件層主要看的是連接池、緩存和隊列。數(shù)據(jù)庫連接池是否被打滿Redis響應時間是否異常消息隊列的積壓量有沒有持續(xù)上升這些往往是整套系統(tǒng)中的水桶短板。數(shù)據(jù)庫層的排查是最常見的瓶頸所在。慢查詢?nèi)罩臼鞘滓P(guān)注點?？吹揭粭l查詢耗時兩秒以上就要去看執(zhí)行計劃確認是否走索引、有沒有全表掃描、預估掃描行數(shù)是多少。操作系統(tǒng)層面主要關(guān)注的是資源水位。比如通過監(jiān)控看到CPU使用率已達90%以上就可以判斷CPU是瓶頸如果內(nèi)存大量交換到Swap就要考慮內(nèi)存容量問題磁盤I/O等待時間過長則要重點關(guān)注磁盤性能尤其是數(shù)據(jù)庫所在盤。這種逐層排查的方式能讓你快速圈定大方向然后逐步聚焦到具體問題的代碼層面。不要試圖一次性分析完所有數(shù)據(jù)那是浪費時間抓住主要矛盾先解決最嚴重的那個問題往往整個系統(tǒng)的性能就能獲得顯著提升。3.2 常見的性能瓶頸類型與典型調(diào)優(yōu)手段性能問題雖然表象多樣但歸結(jié)起來不外乎幾種類型。把每種類型對應的典型場景和調(diào)優(yōu)手段搞清楚排查效率會高很多。CPU密集型瓶頸的一個典型特征是CPU使用率持續(xù)高位但TPS上不去響應時間卻在增長。這種時候需要重點排查是否存在死循環(huán)、密集計算、或者是序列化/反序列化開銷過大等問題。比如某些框架的內(nèi)存序列化操作在低并發(fā)下看起來沒事一上高并發(fā)就暴露出嚴重的CPU消耗。磁盤I/O瓶頸也是高危類型。常見于大量日志寫入、數(shù)據(jù)庫頻繁刷盤、或者文件讀寫密集的業(yè)務場景。如果是數(shù)據(jù)庫所在磁盤導致I/O等待過高可以考慮讓數(shù)據(jù)庫表和索引分離存儲在不同磁盤或者調(diào)整日志的寫入策略。內(nèi)存與GC問題在高并發(fā)Java應用中非常普遍。堆內(nèi)存設(shè)置不合理對象創(chuàng)建過于頻繁或者存在內(nèi)存泄漏都會導致GC頻繁。解決方向包括調(diào)整堆大小參數(shù)、優(yōu)化對象創(chuàng)建邏輯、使用池化技術(shù)復用對象。GC調(diào)優(yōu)要基于GC日志分析不要盲目修改參數(shù)。數(shù)據(jù)庫層面慢查詢和索引失效是兩大高頻問題。慢查詢的典型處理方式是分析SQL執(zhí)行計劃對高頻查詢條件建立合適的聯(lián)合索引避免在WHERE條件字段上使用函數(shù)導致索引失效。數(shù)據(jù)庫連接數(shù)配置過小在高并發(fā)下會導致大量線程等待獲取連接表現(xiàn)為接口RT急劇上升。這類問題的判斷方法是看連接池是否被打滿以及等待獲取連接的時間是否異常。鎖競爭問題在高并發(fā)寫場景下很容易暴露。比如數(shù)據(jù)庫行鎖競爭、分布式鎖的頻繁等待、以及應用層的同步鎖。這類問題的處理往往需要結(jié)合業(yè)務邏輯來優(yōu)化甚至可能需要引入異步化或者隊列不是單純改參數(shù)就能解決的。我整理的常見瓶頸快速判斷參考如下表癥狀可能瓶頸首選排查方向典型手段響應時間漲、TPS不漲應用層線程阻塞/鎖線程Dump、鎖等待分析消除鎖競爭、線程池調(diào)優(yōu)CPU居高不下業(yè)務計算密集/GC頻繁CPU火焰圖、GC日志代碼優(yōu)化、調(diào)整JVM參數(shù)I/O等待高磁盤能力不足/刷盤頻繁iostat、數(shù)據(jù)庫配置磁盤擴容、日志/tmp分離、調(diào)優(yōu)刷盤策略連接數(shù)打滿連接池配置過小/泄漏連接池監(jiān)控、活躍連接數(shù)池大小調(diào)優(yōu)、排查連接泄漏數(shù)據(jù)庫響應慢SQL執(zhí)行計劃問題慢查詢?nèi)罩?、?zhí)行計劃優(yōu)化索引、改寫SQL內(nèi)存持續(xù)上漲內(nèi)存泄漏/緩存過大堆內(nèi)存監(jiān)控、Dump分析修復泄漏、控制緩存上限3.3 調(diào)優(yōu)驗證的方法改一處測一次調(diào)優(yōu)過程中最有價值的習慣是“一次只改一個變量改完就測”。這個道理很簡單但實際操作時很多人忍不住一次性調(diào)整多個參數(shù)結(jié)果出了問題根本看不出來是哪一項改動帶來的效果。舉例來說你發(fā)現(xiàn)數(shù)據(jù)庫連接池太小影響了TPS同時又覺得JVM堆參數(shù)不合理。如果同一次跑壓測前把這兩個都改了測試通過還好一旦性能沒有提升甚至下降你就無法判斷是哪一個改動出了問題只能回頭逐個還原白白浪費時間。正確的做法是先只調(diào)連接池大小重新壓測對比結(jié)果確認有效之后再去調(diào)整JVM參數(shù)再壓測。每一步都留下完整記錄包括改動內(nèi)容、改動前后的測試結(jié)果。這樣你每做的一次調(diào)優(yōu)到底有沒有用一清二楚。調(diào)優(yōu)后的驗證不是只看一個指標至少要從三個維度對比TPS是否提升、平均響應時間和P95/P99是否下降、服務器的資源消耗是否更合理。有時候TPS上去了但P99反而變差說明長尾請求變多了這對用戶體驗來說并不是真正的優(yōu)化。舉個例子某接口平均響應時間從300毫秒降到150毫秒但如果P99從800毫秒漲到1200毫秒那說明少數(shù)用戶的體驗變得更差了這在性能優(yōu)化中是不可接受的。另外如果有條件一定要做多次重復測試取均值尤其是一些對系統(tǒng)影響較大的調(diào)優(yōu)場景。單次測試結(jié)果受網(wǎng)絡波動、系統(tǒng)自身不穩(wěn)定因素影響較大。至少跑三輪取相對穩(wěn)定的一組作為結(jié)果才更可靠。4. 壓測報告編寫與問題排查工具集4.1 一份有說服力的報告應該包含什么性能測試報告是整個性能測試項目的最終交付物也是對外溝通的橋梁。報告寫得專業(yè)與否決定了你的工作成果能不能被業(yè)務方和技術(shù)團隊充分認可。我見過很多測試工程師把大量精力花在執(zhí)行上卻對報告敷衍了事最后效果大打折扣。寫報告時一個核心認知是你的讀者不全是技術(shù)人員。業(yè)務方關(guān)心的是能不能支撐業(yè)務目標管理層關(guān)心的是要不要加機器、需要花多少錢只有開發(fā)團隊才會關(guān)心具體的瓶頸點和方法論。所以一份合格的報告必須兼顧兩類讀者的訴求既要有技術(shù)細節(jié)的深度也要有結(jié)論的清晰表達。我的報告結(jié)構(gòu)一般是這樣組織的測試概述項目背景、測試目標、測試范圍和時間窗口需求與指標定義本次壓測的核心指標和通過標準比如目標TPS、目標RT、成功率測試環(huán)境說明軟硬件配置、網(wǎng)絡拓撲、數(shù)據(jù)規(guī)模、是否與生產(chǎn)一致測試場景設(shè)計業(yè)務模型、并發(fā)模型、壓測規(guī)模和持續(xù)時間核心結(jié)果數(shù)據(jù)TPS、RT平均/P95/P99、成功率、錯誤率等關(guān)鍵指標務必用表格呈現(xiàn)資源監(jiān)控數(shù)據(jù)應用服務器、數(shù)據(jù)庫、中間件的關(guān)鍵監(jiān)控指標問題清單與調(diào)優(yōu)進展發(fā)現(xiàn)的問題、嚴重級別、當前狀態(tài)、調(diào)優(yōu)前后對比結(jié)論與建議是否達到目標、容量預估、擴容建議、后續(xù)優(yōu)化的優(yōu)先級4.2 數(shù)據(jù)呈現(xiàn)的細節(jié)技巧寫報告的時候數(shù)據(jù)呈現(xiàn)方式直接決定了讀者能不能快速抓住重點。對于技術(shù)人員你需要的是趨勢圖、分布數(shù)據(jù)和原始明細對于業(yè)務方和管理層你需要的是一目了然的結(jié)論性數(shù)據(jù)。表格是報告里最常用的呈現(xiàn)方式。TPS、響應時間、成功率、錯誤率這些關(guān)鍵指標一定要放表格里不同場景分不同行使對比清晰。比如基準場景、梯度場景、混合場景、穩(wěn)定性場景分別列出各自的TPS和RT讀者一眼就知道系統(tǒng)在不同負載下的表現(xiàn)。趨勢圖的作用是展示變化過程反映性能拐點。一個典型的場景是當并發(fā)從200升到400時TPS從300升到500這是一個健康的上揚但當并發(fā)從400升到800時TPS不升反降同時RT暴漲這就說明系統(tǒng)已經(jīng)達到瓶頸。這種拐點用圖呈現(xiàn)的效果最直觀。P95和P99這兩個分位值非常值得重視。平均響應時間容易被極端值掩蓋比如一條超時20秒的請求把幾十條50毫秒的請求平均值一下子拉高了。而P95和P99反映的是絕大多數(shù)用戶的真實體驗尤其是P99它代表的是最差的那1%用戶所感知到的性能。給接口調(diào)優(yōu)時我通常更關(guān)注P99的變化。真正有說服力的報告是平均RT不高但P99卻異常高這種對比能直觀地表明確實存在長尾問題具備更大的分析價值。資源使用情況也是報告的關(guān)鍵組成部分。應用服務器的CPU峰值、內(nèi)存水位數(shù)據(jù)庫的慢查詢數(shù)量和連接池使用率這些數(shù)據(jù)與TPS、RT結(jié)合在一起才能解釋“為什么系統(tǒng)表現(xiàn)是這個水平”。比如TPS上不去但數(shù)據(jù)庫慢查詢數(shù)量一直在漲兩者放在同一張報告里結(jié)論自然浮出水面。4.3 常見問題與排查技巧實錄壓測執(zhí)行過程中必然會遇到各種問題有些是系統(tǒng)自帶的有些是腳本自身帶來的。把所有問題都留給開發(fā)去解決是不對的很多問題明明就是壓測方案設(shè)計不到位造成的。腳本相關(guān)的高頻問題最典型的是壓測結(jié)果被參數(shù)相關(guān)性困擾。比如前面接口提取的Token過了有效期后續(xù)接口不斷報權(quán)限異常。這類問題的排查方向是看錯誤日志中報錯的具體原因而不是一有問題就覺得系統(tǒng)掛了。確認問題來源之后再去調(diào)整腳本的關(guān)聯(lián)邏輯。我自己的習慣是壓測過程中隨手開著后端日志窗口一旦看到報錯就立刻對照請求體和返回信息判斷到底是腳本問題還是系統(tǒng)問題。另一種高頻問題是壓測機被打滿。很多人忽略了壓測機自身的性能限制。如果JMeter部署在一臺低配機器上一旦并發(fā)數(shù)上去壓測機自己的CPU先打滿了這時無論系統(tǒng)性能多好測試結(jié)果都不可能準確。判斷的方法很簡單監(jiān)控壓測機的CPU和內(nèi)存如果壓測機CPU持續(xù)100%就需要橫向擴容壓測機了通常用一臺額外機器做分布式施壓。系統(tǒng)類問題中最常見也最容易被忽視的是壓測前的緩存預熱。生產(chǎn)環(huán)境中有大量熱點數(shù)據(jù)常駐緩存而測試環(huán)境是冷啟動狀態(tài)Redis里什么都沒有所有請求都直接打到數(shù)據(jù)庫導致首次壓測的數(shù)據(jù)庫壓力巨大甚至出現(xiàn)大量連接超時。這種問題不解決測出來的結(jié)果毫無參考價值。我的做法是在壓測前做一次“預跑”先用低并發(fā)跑上一段時間讓緩存和數(shù)據(jù)頁填滿等系統(tǒng)穩(wěn)定下來再進入正式壓測階段。另一個實用的排查小技巧是當TPS出現(xiàn)斷崖式下跌時立刻看兩個地方數(shù)據(jù)庫連接池和中間件線程池。這兩個池子一旦被打滿系統(tǒng)會表現(xiàn)為“突然降速但并沒有崩潰”。原因通常是池的排隊等待時間暴增超時丟棄大量請求。遇到這種情況可先做一個快速的定位測試降低并發(fā)數(shù)到原來的1/4如果系統(tǒng)迅速恢復正常基本可以確認是某個池子容量不夠了。4.4 一個值得一用的小工具集工欲善其事必先利其器。性能測試期間用對工具能節(jié)省大把時間。這里分享一些我每次壓測都會用到的工具組合全部基于開源方案沒有授權(quán)問題。壓測執(zhí)行JMeter作為主壓測工具配好參數(shù)化與斷言監(jiān)控采集Node Exporter配合時序數(shù)據(jù)庫存儲用可視化面板展示服務端指標一臺機器即可搭建起來JVM監(jiān)控JDK自帶的Java Flight Recorder排查GC和線程問題相當趁手數(shù)據(jù)庫排查MySQL慢查詢?nèi)罩九浜献詭У男阅芊治龉ぞ呒由螮XPLAIN查看執(zhí)行計劃日志分析先用手頭常用的日志檢索工具或者一條awk命令提取關(guān)鍵信息快速定位異常集中點這套組合完全免費但覆蓋了從施壓到監(jiān)控、再到定位問題的完整鏈路。團隊小、預算不多的情況下這套方案足夠支撐絕大部分性能測試需求。用這些工具時有個經(jīng)驗想分享。監(jiān)控面板不要只看眼前那幾分鐘的數(shù)據(jù)。壓測過程中要定時回看整個時間窗口的趨勢圖因為很多性能問題有一個緩慢演化的過程比如內(nèi)存會隨著測試時間推移不斷增長。只盯著實時數(shù)值看很難發(fā)現(xiàn)這種漸進的趨勢而趨勢恰恰是定位內(nèi)存泄漏類問題的最重要線索。5. 收尾前的一些真心話性能測試做到最后真正拉開差距的地方其實已經(jīng)不是工具用得熟不熟、腳本寫得好不好而是對整個測試過程閉環(huán)的把控能力。從需求到執(zhí)行從定位到報告每一環(huán)都要經(jīng)得起推敲。我個人的體會是性能測試報告的結(jié)尾不應該只是羅列問題更要有明確的問題優(yōu)先級和整改建議。建議要能落地比如“連接池參數(shù)建議從20調(diào)整到50預期可提升多少”這樣的表述而不是籠統(tǒng)說“建議優(yōu)化系統(tǒng)性能”。報告只有做到這個顆粒度才會被開發(fā)和運維真正重視測試工作也才能真正推動系統(tǒng)進步。最后再分享一個小技巧。無論項目多急壓測執(zhí)行完了一定要留出時間回看一遍全部腳本和配置特別是參數(shù)化文件里的數(shù)據(jù)是否被耗盡、關(guān)聯(lián)提取的正則表達式是否涵蓋邊界情況。很多壓測數(shù)據(jù)的異常最后追根溯源都是這些“小細節(jié)”的問題。性能測試沒有驚心動魄的高光時刻靠的恰恰是細節(jié)處一點一滴的累積。把這些基礎(chǔ)功夫做扎實了你寫的每一份報告都會站得住腳。