雲時代的應用性能測試挑戰
系統容量相比傳統應用數量級增長
微服務化架構，調用關係更加複雜
用戶增長迅速，資源突發需求量大
▼▼▼
傳統性能測試工具性能不足，自研技術門檻高
瓶頸在各微服務間漂移，測試技術難度大
如何摸清資源擴容模型，有限資源下如何驗證性能
一旦性能問題流入現網，問題定位週期長
華爲雲性能測試實踐方案如何更加系統的開展性能測試活動
1. 被測對象分析（某社交類APP）
從系統架構分析可能出現的瓶頸點，作爲重點測試場景
Feed流會頻繁操作後臺的Redis等服務，每次操作會產生100+次網絡操作，200+次key/Value運算，因此會成爲系統的主要性能瓶頸
備註：Feed是將用戶主動訂閱的消息源組合在一起形成內容聚合器，幫助用戶持續地獲取最新的訂閱源內容，在社交類應用中被廣泛使用若干
2. 測試場景分析建模
業務特點：用戶增長迅速、突發事件高流量併發
Step1：以使用場景爲主線，構建性能模型（使用角色、使用階段等）
Step2：分析每個操作場景的影響因子，如好友、關注數量等，建立每個場景的測試模型
單場景一級接口測試
單場景二級接口測試
如需測試某個對性能的影響，可遞增方式改變因子值進行測試
按照頁面權重分配壓力模型，實際在生產環境比例會不斷變化，因此在性能摸底過程中需要不斷調整摸底
示例：全頁面混合壓測模型
3. 測試工具需求分析
識別關鍵場景測試需求
1) HTTP協議/Rest接口
2) 用戶登陸認證 ，模擬多用戶操作
3) 支持接口串聯場景，需要上下文關聯
4) 性能暫無基線，需要支持遞增模式快速摸底
5) 各頁面用戶量未知，需要靈活調整混合模型配比
6) 由於社交類應用業務增長迅速，因此需要支持按需使用，隨時擴大工具的併發量
7) 需要支持10萬以上的併發
8) 測試結果易於觀察、保存
9) 提供監控能力，便於快速定位
4. 測試服務選型與搭建
測試服務選項原則：功能滿足、效率高（即開即用）、成本低
華爲雲性能測試服務CPTS更適合測試高擴展性的大規模分佈式系統
5. 測試執行
分層開展性能測試，在集成階段確保性能測試活動可開展
測試執行的一些典型問題
性能是一個逐步提升的過程，測試過程中需要找到擴容的模型，從不足50的TPS提升至萬級
6. 測試結果分析
1.1 如何從測試工具側快速分析被測對象可能存在的問題
-
存在部分響應超時：
a) 服務器繁忙,如某個服務節點CPU利用率高
b) 網絡IO超過VM/EIP帶寬
c) 等待後端微服務、數據庫的超時時間設置過長 -
運行一段時間後全部響應超時或者檢查點校驗不通過：
a) 大壓力導致系統中某個微服務奔潰
b) 後端數據庫無響應 -
TPS未隨着併發數增長而上升：
a) 系統性能到達瓶頸，持續併發加壓過程中響應時延增加（可觀察響應區間統計）
b) 可通過進一步加壓是否會出現非正常響應驗證 - TP90響應時延較短，TP99時延高：
a) 系統性能接近瓶頸
b) 可通過進一步加壓是否會出現非正常響應驗證
1.2 一些通用優化建議
1) 擴容，鏈路中的某一應用可能出現cpu使用率較高或者連接池資源不夠用(rpc、jdbc、redis連接池等)但本身對於拿到連接的請求處理又很快，這一類需要橫向擴展資源。
2) 應用邏輯優化，比如存在慢sql、 邏輯的不合理如調用db或者redis次數過多、沒有做讀寫分離造成寫庫壓力過大。
3) 超時時間的合理設置，對於應用之間的rpc調用或者應用與其他基礎組件之間的調用，均需要設置合理的超時時間，否則過長的等待將造成整個鏈路的故障。
4) 緩存的應用，請求儘可能從前端返回，而不是每一個都要讓後端應用處理後再返回，減輕後端應用及數據庫壓力，提高系統吞吐能力。
5) 限流，對於超出承載能力的QPS或併發，可以進行攔截並直接返回提示頁面。
6) 降級，對於非核心鏈路上的應用，允許故障關閉而不影響核心鏈路
7) 擴容和優化也是有限度的，在評估容量內，保障核心交易鏈路正常是重中之重，對於非核心功能模塊考慮降級場景
某互聯網平臺案例
業務特點：突發事件高流量突發，如瞬間由百級用戶增長到萬級
對於網絡架構複雜的應用，可以通過網絡架構上的分段驗證，如分別從最外端的CDN入口（1）中間的ELB（2）業務層（3）分別做測試，驗證網絡架構上的瓶頸和影響
性能測試服務關鍵能力要求
