性能測試項目實戰(zhàn)：應(yīng)用加載慢該怎么辦？

 背景  


app收到留學(xué)push、課堂、資訊，用戶點擊push消息，進(jìn)入app，應(yīng)用加載很慢，容易出現(xiàn)應(yīng)用假死、app崩潰或提示網(wǎng)絡(luò)異常等信息。


給用戶體驗十分不友好，監(jiān)控阿里云資源tcp連接數(shù)飆高，cpu打滿，自愈能力（系統(tǒng)恢復(fù)能力）低。



  分析  



push頻率過高(這本身沒有問題)，從而導(dǎo)致收到push的用戶過多，如果按10000的push到達(dá)，20%的用戶同時點擊，那么將造成大于等于200的用戶并發(fā)量。


從服務(wù)器看資源：cpu、內(nèi)存、磁盤I/O一切顯示正常，但是業(yè)務(wù)處理存在漏洞，即離線app收到推送，打開push時，接口請求過多，一度達(dá)到30+接口，又或者可能出現(xiàn)服務(wù)器出現(xiàn)短暫網(wǎng)絡(luò)波動，即帶寬過大(大于設(shè)定值5Mbit/s)，服務(wù)器自動恢復(fù)，影響范圍約2min甚至更久，同時監(jiān)控阿里云tcp連接數(shù)在短暫時間里達(dá)到4-6k的連接數(shù)，超出平均水平一大截<需要壓測得出一個極限值>。


小知識：理論1個tcp連接數(shù)對應(yīng)1個http請求，1個push進(jìn)入app，觸發(fā)了3個或多個http請求，但是http2.0是支持并行請求tcp連接，那么1個用戶請求的多個http請求創(chuàng)建的也是1個tcp連接，http1.1默認(rèn)帶connection參數(shù),保持持久連接。


但是該版本不能并行請求，出現(xiàn)的是多對多的關(guān)系，然后nginx可以配置http的協(xié)議版本？


 結(jié)果 


大致可以判斷出，前面用戶批量請求服務(wù)器，創(chuàng)建tcp連接過多，用戶持續(xù)繼續(xù)訪問，那么tcp連接不能及時釋放<處理更多htttp請求>，那么造成服務(wù)器tcp連接數(shù)過高，app沒有接收到后端響應(yīng)故而服務(wù)器響應(yīng)出現(xiàn)請求超時。


這時候需要性能測試，得出系統(tǒng)、應(yīng)用程序瓶頸進(jìn)行調(diào)優(yōu)。


準(zhǔn)備性能測試環(huán)境


包括用戶(業(yè)務(wù))數(shù)據(jù)、接口信息、開發(fā)測試腳本等。




  設(shè)計性能測試用例  



前提是了解業(yè)務(wù)流程，建立業(yè)務(wù)模型，即有可能出現(xiàn)性能問題的點，那么在開發(fā)腳本時也會對此進(jìn)行單接口、組合場景的設(shè)計。


如背景現(xiàn)象描述，用戶收到push，從此進(jìn)入app應(yīng)用請求其他資源，那么需要獲取這幾個請求的接口，作為一個整體事務(wù)請求，業(yè)務(wù)分析、iOS離線推送將每個tab首頁都加載了，請求接口過多，需要拆分添加子事務(wù)進(jìn)行監(jiān)控。


即推送app、發(fā)起push、點擊push整體作為一個事務(wù)請求，其中首頁、上課、考試、留學(xué)等根據(jù)需求拆分子事務(wù)。


場景設(shè)計


假設(shè)沒有緩存，先關(guān)閉redis服務(wù)，進(jìn)行壓測，逐步加壓，例如1、10、20、50、100、200、300、500進(jìn)行5分鐘持續(xù)并發(fā)壓測，收集性能結(jié)果。


現(xiàn)象還原


通過不斷加壓并發(fā)，得出服務(wù)器所承受最大并發(fā)數(shù)，系統(tǒng)出現(xiàn)瓶頸，根據(jù)監(jiān)控的結(jié)果分析，開始優(yōu)化：加緩存、代碼優(yōu)化、sql建立索引，再重復(fù)壓測，以出現(xiàn)現(xiàn)象的并發(fā)數(shù)進(jìn)行壓測，結(jié)果是否較調(diào)優(yōu)前有優(yōu)化（標(biāo)準(zhǔn)：tps、響應(yīng)時間、app現(xiàn)象等）。


性能指標(biāo)計算公式：tps=通過事務(wù)總數(shù)/運行腳本總時長。


首頁代入一個性能概念：Vuser、TPS、RT，隨著用戶數(shù)遞增請求，響應(yīng)時間隨之遞增、通過事務(wù)數(shù)也會增加。


a、隨著用戶數(shù)增加，持續(xù)并發(fā)一段時間，RT、TPS也會隨之平穩(wěn)逐步增加，即上下波動略小，正?，F(xiàn)象，但是需要分析rt、tps是否達(dá)到預(yù)期；


b、隨著用戶數(shù)增加，持續(xù)并發(fā)一段時間，RT猝然上漲、服務(wù)器可能出現(xiàn)cpu被打滿，應(yīng)用程序無法響應(yīng)；


c、隨著用戶數(shù)增加，通過事務(wù)數(shù)遞增，響應(yīng)時間遞增<終究達(dá)不到預(yù)期>，tps上不去，表示服務(wù)器處理能力低，需要分析原因。




  收集性能測試結(jié)果  


進(jìn)行結(jié)果分析


1、tps上不去的原因：由簡入繁排第一位的首先檢查網(wǎng)絡(luò)帶寬--連接池<服務(wù)器>--垃圾回收機(jī)制--數(shù)據(jù)庫配置<如果需要寫庫>--通訊機(jī)制--硬件資源--負(fù)載機(jī)資源不足--腳本設(shè)計問題<需要從場景設(shè)計方向入手>--系統(tǒng)架構(gòu)--并發(fā)數(shù)設(shè)置問題；解決的第一個問題就是檢查寬帶只有3M，流量無法進(jìn)來<請求服務(wù)>，被擋在外面。





2、正?，F(xiàn)象是可以看到tps隨著用戶的遞增而遞增。





3、響應(yīng)時間也是隨著并發(fā)用戶數(shù)遞增而遞增。




4、在腳本運行之前初始化Vuser虛擬用戶，隨著并發(fā)用戶的遞增，響應(yīng)時間也隨之遞增，在期望響應(yīng)時間對應(yīng)的縱坐標(biāo)用戶數(shù)，即為最優(yōu)并發(fā)用戶數(shù)<不要看響應(yīng)時間上的縱坐標(biāo)標(biāo)識的用戶數(shù)>。





5、單機(jī)目前負(fù)載生成的用戶，無論何種壓測策略，都無法將服務(wù)器壓垮或者app出現(xiàn)無法正常響應(yīng)事件，需要分布式壓測。




6、在uat環(huán)境壓測，當(dāng)并發(fā)用戶數(shù)上去之后，服務(wù)器資源cpu暴漲，出現(xiàn)服務(wù)假死狀態(tài)，jvm排查線程，發(fā)現(xiàn)是底層框架導(dǎo)致。




作者：我先測了


歡迎關(guān)注微信公眾號 ：Python測試社區(qū)