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

 背景  


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


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



  分析  



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


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


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


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


 結果 


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


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


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


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




  設計性能測試用例  



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


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


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


場景設計


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


現(xiàn)象還原


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


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


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


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


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


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




  收集性能測試結果  


進行結果分析


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





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





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




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





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




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




作者：我先測了


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