直播 APP 后端性能測試思路

原創發布：https://www.cnblogs.com/huanghaopeng/
作者信息：HHP

一、概述

直播 APP 場景中通常包含主播（+輔麥主播）、粉絲 2個主要角色

• 主播主要的交互以推流為主，粉絲主要的交互以拉流為主
• 另外包括粉絲與主播之間的互動，文本消息、表情、送禮物

直播的中的用戶核心性能體驗為：主播與粉絲之間的交互延遲，而推流是直播第一步，如果推流不穩定，無論如何優化體驗都會非常差。

二、性能需求

關鍵角色	性能體驗
用戶視角	第一個畫面加載延遲（首次緩沖）、直播畫面延遲、卡頓、弱網體驗、流量消耗
運維視角	CDN、帶寬開銷、核心業務的橫向擴容能力、（政策原因）對流媒體進行存儲產生的存儲空間開銷
開發視角	延遲和卡頓的平衡（客戶端緩存）
運營視角	/

三、測試實現

1）通訊協議

推、拉流的通訊

• 網絡層：Socket 或 St 負責傳輸
• 協議層：RTMP 或 HLS 負責網絡打包（主播連麥：WebRTC）
• 封裝層：flv、ts 負責解碼數據封裝
• 編碼層：h.264、acc 負責圖像、音頻壓縮

非推、拉流的通訊

• HTTP、WebSocket

2）測試工具

工具	支持協議	說明
St-load	RTMP	（Linux）通過模擬並發的推拉流實現特定負載的測試
Locust	自帶 HTTP Client，其它協議需自行實現 Client	采用（單進程）協程+IO復用實現並發負載

四、測試策略

說明：直播類壓測的核心是驗證並發下推、拉流的順暢，是協議層的測試。用戶體驗的關鍵是和主播之間的交互延遲。

1）核心角色與業務

• 主播 - 直播 - 抓流/推流
• 主播 - 互動 - 查看/回應粉絲的互動
• 粉絲 - 直播 - 切換直播間
• 粉絲 - 直播 - 拉流
• 粉絲 - 互動 - 評論、打賞等互動行為

2）測試用例編寫參考

• 參考上條，略

3）測試場景設計關注點

1、性能基准

建立性能基准

• 對 並發推流 進行測試
• 對 並發拉流 進行測試
• 對 粉絲 進入直播間 的首次緩沖延遲（包括：首包用時延遲、視頻首幀延遲） 進行測試
• 對 特定的 碼率、幀率 所對應帶寬開銷進行測試
• 對並發 進入直播間 時的內容交互加載延遲進行測試
• 直播間中的主播與粉絲交互延遲
• 對 弱網環境 進行不同程度的並發測試

2、負載測試

• 關注 日度 業務峰值負載（業務量、時間、時長）
• 關注 周/月 中業務峰值負載（業務量、時間、時長）
• 關注 運營推廣 過程中所涉及的業務負載（業務量、時間、時長）
• 關注 意外負載 的出現時機、負載特點

3、容量測試

• 基於“性能基准”結果，參考：1000 - 2000 - 3000 - XXXX 的方式進行主播遞增推流測試
• 關注 良好性能體驗 條件下的最高支持在線主播數量
• 關注 可容忍上限 條件下的最高支持在線主播數量
• 關注 系統資源充裕 條件下的最高在線主播數量
• 關注 系統資源不足 條件下的最高在線主播數量

4、可用性測試

• 以施加峰值負載的方式達到考核時間周期的業務量

5、可靠性測試

• 關注 網絡異常 / 弱網環境 對性能基准的影響
• 關注 服務異常 對性能基准的影響
• 關注 冗余節點 隨機的上、下線對性能基准的影響
• 關注 冗余節點 隨機的上、下線對：功能可用性、事務性、性能、持久化設計 的影響

6、資源規划 / 擴容配置

• 關注核心業務在性能上橫向擴容過程中，節點增加與性能削減的關系
• 關注主播推流對服務產生的存儲空間占用開銷
• 關注主播推流對服務產生的帶寬占用開銷

4）測試場景設計

（參考產品設計 與“測試場景設計關注點”：略）

測試場景	場景描述	場景目標	執行策略	期望結果
性能基准測試
負載測試（推、拉流）
負載測試（HTTP、WS流）
容量測試
可用性測試
可靠性測試
……

五、備注

• 腳本需要實現粉絲端首次緩沖時間的延遲測試，即對首包、首幀畫面的斷言、延遲、丟幀判斷測試。