隨着帶寬提速和互聯網發展,內容豐富、形式多樣的視頻正成爲碎片化時代娛樂消費的新寵,短視頻、視頻直播、在線鋼琴陪練、合唱直播一系列新玩法層出不窮,涉及電競、社交、電商、教育等各個行業。網絡視頻快速發展對系統性能帶來了巨大的考驗。html
下面是用戶與流媒體服務器的簡化交互關係,主要分爲推流和拉流2大類。緩存
推流就是從外界採集數據後利用流媒體協議將文件推流至流媒體服務器端,拉流就是將文件從流媒體服務器拉取至本地播放的過程,流媒體的文件主要是由音頻和視頻2個部分組成,youtube、土豆、優酷等視頻播放器播放一個互聯網上的視頻文件時,須要通過解協議、解封裝、音視頻解碼、以及音視頻同步這幾個步驟。所以對流媒體的壓力測試也需經歷這些過程,因此先了解幾種常見的流媒體協議:服務器
HLS:HTTP Live Streaming(HTTP直播流技術),Apple的動態碼率自適應技術,不一樣帶寬的設備能夠自動切換到最適合本身碼率的視頻播放。HLS基於http短鏈接,將整個流切分紅一個個小的文件來下載,也就是ts切片文件,並更新m3u8的索引文件、存放ts文件配置信息和相關路徑。m3u8由一系列的標籤組成,ts文件爲傳輸的流文件,視頻編碼主要格式h264/mpeg4,音頻爲acc/MP3。HLS的主要缺點就是時延性在10秒以上。網絡
RTMP:Real Time Messaging Protocol(實時消息傳輸協議),該協議基於TCP ,使用端口1935,每一個時刻的數據收到了便可轉發,RTMP協議須要客戶端和服務器經過「握手」來創建基於傳輸層連接之上的RTMP Connection連接,在這個鏈接上傳輸對應的控制信息和對應的Message,RTMP的實時性比HLS要好,每每時延在5S如下。而且RTMP有RTMPT,RTMPS等變種。併發
下面咱們來了解下流媒體播放的主要流程,流媒體播放主要分爲直播和點播2大類,區別在於直播是利用一些新興或者傳統的媒介實時的進行圖像和聲音的採集,如錄像機,麥克風、手機等,將採集的數據進行處理和編碼,利用上面提到了流媒體協議進行封裝,以後將數據流推送到直播節點上,觀衆能夠實時進行觀看。點播的數據來源則是已存在的視頻,或者是經過直播流錄製轉換後的視頻,能夠回放觀看。以後流媒體服務器經過CDN分發網絡,根據拉流端的碼率實時轉碼,就近的將數據流發送至客戶端,縮短請求響應時間。負載均衡
觀衆端最終經過播放器解碼、在不一樣的地點播放觀看對應的直播視頻和點播視頻。然而不一樣的站點和播放器觀衆體驗大相見庭,有的時候咱們會說這個視頻特別流暢,或者特別卡,從觀衆的角度具體有哪些直觀的體驗維度呢?異步
下面是幾個主要影響用戶觀看體驗的指標:高併發
視頻/短視頻領域當前行業競爭十分激烈,服務質量每每會成爲服務提供商生存的生命線,單在技術上主要面臨着如下幾個挑戰:工具
• 海量併發場景常見
不一樣於普通應用和遊戲,視頻類應用的使用時間很是集中,大體在晚飯後至睡前22點-23點,在短短几小時內涌入大量用戶,例如一個大V/流量明星直播能夠引發百萬級用戶的登陸。海量的併發用戶經常形成視頻卡頓、畫面延時甚至應用崩潰,這已經成爲企業不能承受之重。
• 用戶對高延遲容忍度降低
隨着互聯網網速的變快,用戶的耐心程度正不斷降低,視頻加載時間每長1秒,就會有約6%的人放棄觀看。對直播來講即時性就顯得尤其重要,若是主播端與觀衆端的互動沒法同步時,給用戶帶來很差的體驗。
• 用戶交互頻率高
視頻應用與普通應用相比,涉及不少的用戶交互頻次高的場景,視頻流服務器除了承擔併發用戶壓力以外,還包括用戶消息推送、禮物、聊天、紅包雨等場景帶來的數據交互壓力。這些用戶交互頻次高的場景同時涉及大量外部API接口,時刻影響着用戶體驗。性能
視頻/短視頻公司爲了快速搶佔市場,必須快速的攻克這些挑戰,利用當下的一些新興的技術,提高服務器性能。像是經過GOP緩存,改寫播放器邏輯,讓播放器在拿到第一個關鍵幀後就直接顯示而不是等待音視頻同步後再進行播放;創建CDN內容分發網絡,通過策略部署,負載均衡,下降服務器和帶寬的壓力;提早作好DNS解析,提升視頻文件下載性能;以及對服務器進行壓力測試,圍繞客戶播放行爲識別性能瓶頸,進行優化。
流媒體的壓測測試主要是經過模擬海量用戶訪問直播點播的場景,關注於服務器是否可以在高併發時間段穩定運行,在播放視頻時不出現卡頓、花屏等問題影響用戶觀看體驗,以及是否能夠及時響應秒開視頻等。
視頻卡頓主要有2個大方面的因素:
1) 外因,客戶端的設備配置太差,對應的硬件來不及處理數據,或者對應的軟件版本過低,這樣只能是升級硬件以及更新版本。另外一個是網絡太差,隨着網絡通訊的快速發展,對數據傳輸的要求也隨之增長,在數據來不及發送客戶端出現了等待數據的狀況,也會致使視頻卡頓;
2) 內因,流自己出現了音視頻時間戳不一樣步,流對應的參數不正確致使的視頻卡頓。另外,經過視頻首幀用時和首包用時能夠客觀的量化用戶的觀看體驗,這些都是流媒體進行壓力測試須要主要關注的問題。
視頻出現花屏的主要可能:
1) 丟失了關鍵幀或者沒有從關鍵幀開始解碼。對於H.264碼流來講,分爲I、B、和P三中類型的幀,其中I幀爲關鍵幀,能夠獨立的解碼播放,B 幀是雙向預測內插編碼幀,丟失了I幀和後面的P幀,則會解碼失敗,P 幀是前向預測編碼幀,丟失了前面的I、B、P幀也會致使解碼失敗。對於此類的解碼失敗通常就會出現花屏的現象。
2) 圖像格式的轉換不正確,例如橫屏播放變成了豎屏播放,拉流端圖像尺寸發生了變化須要重置對應的×××,不然容易出現花屏。
3) 渲染出現了髒數據,主要就是尚未完成渲染的數據被送到了編碼器編碼,致使圖像錯位,或者撕裂等。
那麼驗證流媒體服務器的性能,保障流媒體的質量顯的尤爲重要。咱們在網絡上搜索流媒體壓力測試時能看到基於srs-librtmp實現的srs-bench的開源工具,可是該工具在進行壓力測試時看到的性能指標有限,只有數據包的時間長度和對應的大小和等待時間,這個沒法客觀的體現用戶體驗,而且該工具沒法知足chunked的方式,測試場景受到很大的限制。
而華爲雲性能測試服務(CPTS)針對以上場景,針對以上測試場景的訴求,加強支持了能夠兼容HLS和RTMP的流媒體壓測能力,可進行端到端的壓力測試,壓測業務流量以下圖所示
CPTS利用執行機模擬大量併發用戶的客戶端向CDN或者源站發起請求,模擬拉流操做,CDN或者源站在收到請求後,會將響應報文返回至CPTS壓測執行機,以HLS協議點播爲例,CPTS壓測執行機經過對CDN或者源站發起請求,獲得m3u8索引文件,按序請求下載獲取每一段ts數據流。解析對應的ts流,實時計算視頻的幀率、碼率、首包用時和首幀用時,以後還將利用異步線程模擬播放流媒體文件,識別視頻是否出現卡頓和花屏,模擬CDN或者源站在高壓力場景下,客戶端收到視頻流在實際播放過程當中是否會產生的問題。
在視頻場景上,支持點播和直播兩種模式,而且大大豐富了針對視頻播放的質量監控指標,能夠動態獲取視頻壓測時對應的視頻首包用時、首幀用時、平均下載速度、碼率、幀率、帶寬等性能指標,下表爲具體的流媒體性能測試指標,以及對應的參考值。
指標 | 定義 | 建議值 |
---|---|---|
併發用戶數 | 在性能測試工具中,併發用戶數通常被稱爲虛擬用戶數。 | |
丟包率 | 丟包是網絡中數據傳輸的時候出現數據丟失的現象,丟包率是指丟包數據佔總傳輸數據的百分比。 | 網絡丟包率越高,網速越慢,通常丟包率小於1%屬於正常。 |
平均下載速度 | 指播放器播放視頻過程當中下載視頻資源的速度。平均下載速度=總下載字節數/吞吐用時。 | 優秀 >180 KB/s,通常 >70 KB/s,差 ≤ 70KB/s |
視頻首包用時 | 從獲取視頻真實地址到獲取視頻資源第一包之間的時間間隔。 | 優秀 ≤1s,通常 ≤2.5s,差 >2.5s |
視頻首幀用時 | 從獲取視頻真實地址到開始播放視頻第一幀之間的時間間隔。其中視頻秒開指視頻頁面首屏在1s左右快速的展示出來,視頻秒開直接影響用戶體驗。 | 優秀 ≤1s |
平均幀率 | 幀率用於測量顯示幀數的量度,單位爲每秒顯示幀數(FPS) | 卡頓 < 24FPS |
卡頓率 | 即將支持 | |
花屏檢測 | 即將支持 |
下面咱們利用CPTS對流媒體服務器進行壓力測試,模擬200個用戶同時觀看直播對流媒體服務器帶來的壓力。
下圖爲對應的實時報告,首先查看是否存在錯誤信息,能夠看到當200個用戶對服務器進行併發訪問時,存在12次的鏈接錯誤,說明服務端在當前壓力下沒法正常處理HLS直播連接,會致使這部分用戶沒法打開視頻。
由上圖能夠看出該場景下,視頻平均幀率爲24fps,這是因爲測試樁固定幀率爲24fps,通常在視頻的性能測試中,若是幀率小與24fps時用戶能感知到視頻卡頓;經過平均首包用時和平均首幀用時客觀體現用戶體驗,若是平均首包用時小於1s,用戶體驗感較好;該測試結果爲1.09s大於1s,用戶體驗通常;若是平均首幀用時小於1s時,用戶體驗感好,該測試結果爲2.58s大於2.5秒,用戶體驗較差;由於碼率的大小必定程度決定視頻文件的清晰度、流暢度,碼率越高,畫質越好,因此測試報告中展示出碼率的動態變化曲線;另外展現出上行帶寬和下行帶寬實時數據,查看網絡情況。經過這些視頻指標可快速對服務器能力進行評估。
經過CPTS可以快速的對流媒體進行壓力測試,並將用戶體驗指標量化,直觀的透過數據報告指標展現用戶體驗優劣。CPTS服務免去用戶搭建環境的時間成本和人力成本,只需重點關注業務的開發及性能的提高,將性能測試化繁爲簡,暢享雲端體驗。