1. 程式人生 > >大規模分散式系統性能測試實踐

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

一、雲時代的應用效能測試挑戰

二、華為雲效能測試實踐方案如何更加系統的開展效能測試活動

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


三、某網際網路平臺案例

業務特點:突發事件高流量突發,如瞬間由百級使用者增長到萬級

對於網路架構複雜的應用,可以通過網路架構上的分段驗證,如分別從最外端的CDN入口(1)中間的ELB(2)業務層(3)分別做測試,驗證網路架構上的瓶頸和影響

應用內部的效能瓶頸如何提升定位效率?


四、效能測試的最後一公里

整合APM,解決效能問題定位最後一公里問題,大幅提升效能測試效率

如:xxx併發情況下,服務A呼叫服務B的事務1出現問題,並直接定位至出錯函式

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

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

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

應用拓撲

事務監控

呼叫鏈跟蹤

 

五、效能測試服務關鍵能力要求