大規模分佈式系統性能測試實踐

1、雲時代的應用性能測試挑戰

2、華爲雲性能測試實踐方案如何更加系統的開展性能測試活動

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.  測試服務選型與搭建

測試服務選項原則：功能知足、效率高（即開即用）、成本低

雲服務更適合測試高擴展性的大規模分佈式系統：https://www.huaweicloud.com/product/cpts.html

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)      擴容和優化也是有限度的，在評估容量內，保障核心交易鏈路正常是重中之重，對於非核心功能模塊考慮降級場景

3、某互聯網平臺案例

業務特色：突發事件高流量突發，如瞬間由百級用戶增加到萬級

對於網絡架構複雜的應用，能夠經過網絡架構上的分段驗證，如分別從最外端的CDN入口（1）中間的ELB（2）業務層（3）分別作測試，驗證網絡架構上的瓶頸和影響

應用內部的性能瓶頸如何提高定位效率？

4、性能測試的最後一千米

集成APM，解決性能問題定位最後一千米問題，大幅提高性能測試效率

如：xxx併發狀況下，服務A調用服務B的事務1出現問題，並直接定位至出錯函數

• 在上線和活動前期經過雲性能測試服務進行壓力測試，發現部分接口的響應時間比較長，會出現比對失敗和響應超時，經過APM的調用鏈分析，發現有部分SQL語句比較耗時，針對這些SQL查詢語句，創建了索引，快速定位問題並迅速解決。

• 最終通過兩輪測試優化後，官網首頁訪問響應超時與正常返回比提高了43.3%，預定試駕場景響應超時與正常返回比下降到0，提高了100%。

• 性能瓶頸定位時間，從官網未使用APM時須要1周，縮短到俱樂部使用APM後的0.5天，效率提高90%

應用拓撲

事務監控

調用鏈跟蹤

 

5、性能測試服務關鍵能力要求