WebRTC進(jìn)行壓測的思路及方式和一些經(jīng)驗(yàn)

最近幾年WebRTC特別火，但如何對WebRTC服務(wù)進(jìn)行壓力測試是一個很有難度和挑戰(zhàn)的工作，因?yàn)閃ebRTC客戶端實(shí)際使用上產(chǎn)生的壓力瓶頸主要來源對象是碼流而非傳統(tǒng)的HTTP并發(fā)請求。因?yàn)闃I(yè)務(wù)要求服務(wù)至少能支持提供300路并發(fā)，于是準(zhǔn)備300路WebRTC連接驗(yàn)證下SFU服務(wù)器壓力情況，這里分享進(jìn)行壓測的思路及方式和一些的經(jīng)驗(yàn)，如果在這方面有相關(guān)經(jīng)驗(yàn)的測試技術(shù)方案的測試同行，請加評論給予指導(dǎo)幫助。

Webrtc壓測主要問題：

1.那么多的壓力客戶端從哪里來？

2.如何監(jiān)控服務(wù)器性能？

第一個問題：第一想法是請服務(wù)端開發(fā)同事出一份Linux C++版本W(wǎng)ebRTC客戶端的代碼。支持開上百個線程對應(yīng)上百個WebRTC客戶端，然后跑在多臺服務(wù)器上開始壓測，讀取本地視頻流和音頻流作為輸入。后來經(jīng)過溝通感覺有點(diǎn)給開發(fā)同事增加了不少測試內(nèi)容的工作量，再加上開發(fā)同事的時間也很緊張。經(jīng)過與廠商的溝通以及網(wǎng)上沖浪調(diào)研，找到了解決這個問題的方案，準(zhǔn)備通過使用playwright模擬瀏覽器作為WebRTC壓力的客戶端完成請求，并讀取本地文件作為音視頻輸入。

第二個問題：經(jīng)過討論服務(wù)端開發(fā)可以自行搭建監(jiān)控服務(wù)，然后接入到grafana，增加可視化模板，就可以獲取到用戶連接數(shù)、RTC流數(shù)量、CPU使用率、服務(wù)器實(shí)時碼率、服務(wù)器消耗流量、內(nèi)存使用等數(shù)據(jù)。（PS）內(nèi)存監(jiān)控需要自行配置，要有內(nèi)存回收機(jī)制，另外limited內(nèi)存需要設(shè)置合理。 開始測試之前我們要先搞清楚被測系統(tǒng)的框架，我們知道在WebRTC技術(shù)的實(shí)際應(yīng)用中，衍生出了媒體服務(wù)器的用法，那媒體服務(wù)器區(qū)分成MCU（Multipoint Control Unit）和SFU（Selective Forwarding Unit）兩類網(wǎng)絡(luò)結(jié)構(gòu)。MCU是一種傳統(tǒng)的中心化網(wǎng)絡(luò)結(jié)構(gòu)，參與者僅與中心的MCU媒體服務(wù)器連接。MCU媒體服務(wù)器要合并所有參與者的視頻流，生成一個包含所有參與者畫面的視頻流，參與者只需要拉取合流畫面。而在SFU網(wǎng)絡(luò)結(jié)構(gòu)中，雖然仍有中心節(jié)點(diǎn)媒體服務(wù)器，但是中心節(jié)點(diǎn)只負(fù)責(zé)轉(zhuǎn)發(fā)，不做合流、轉(zhuǎn)碼等資源開銷較大的媒體處理工作，所以服務(wù)器的壓力會小很多，服務(wù)器配置也不像MCU的要求那么高。每個參與者需要1個上行鏈路和N-1個下行鏈路，帶寬消耗高于MCU。那我們本次被測試系統(tǒng)架構(gòu)使用的是SFU網(wǎng)絡(luò)結(jié)構(gòu)，如下：



我們搞清楚系統(tǒng)框架后，為實(shí)現(xiàn)壓力測試目標(biāo)，需要使用具備以下幾點(diǎn)的自動化工具：

◆穩(wěn)定且可預(yù)測的設(shè)備及運(yùn)行網(wǎng)絡(luò)；
◆能在不同條件下進(jìn)行測試，可動態(tài)控制的可配置網(wǎng)絡(luò)；
◆可以測試來自不同地點(diǎn)的用戶；
◆對結(jié)果進(jìn)行詳細(xì)的可視化分析，以方便理解測試結(jié)果。 接下來走入正題，開始進(jìn)入測試工作。

編寫webrtc壓力客戶端代碼

因?yàn)閳F(tuán)隊(duì)想看到實(shí)際壓測中的全鏈路表現(xiàn)，比如房間管理，分散均勻的進(jìn)入不同會議室，和多人進(jìn)入一個會議室通話情況等。

開始腳本工具調(diào)研，playwright是微軟開源的自動化UI測試工具，支持Chrome、Firefox、Edge等多種瀏覽器，兼容多種語言、多種操作系統(tǒng)。

它基于Websocket協(xié)議，可以接受瀏覽器（服務(wù)端）的信號。

Playwright安裝簡單，pip安裝時會自動下載瀏覽器驅(qū)動： pip install playwright playwright install， 安裝時會自動下載瀏覽器依賴，windows系統(tǒng)在%USERPROFILE%AppDataLocalms-playwright 路徑下。

使用： from playwright.async_api import async_playwright 網(wǎng)上很多帖子就不過多贅述了。

具體Webrtc核心測試代碼：



args 使用如下參數(shù)啟動即為下面的效果：

f"--use-fake-device-for-media-stream",

f"--use-fake-ui-for-media-stream"



如果想讀取本地視頻及碼流作為webrtc client 音視頻為輸入即為下列參數(shù)：

f"--use-fake-device-for-media-stream",

f"--use-fake-ui-for-media-stream",

f"--no-sandbox",

f"--use-file-for-fake-video-capture=./webrtctest/1.y4m",

f"--use-file-for-fake-audio-capture=webrtctest/2.wav"

調(diào)試代碼中，在基礎(chǔ)代碼上進(jìn)行封裝，首先準(zhǔn)備一個csv文件，里面可以存鑒權(quán)使用的authCode之類的信息，同時按行讀取csv，并且會根據(jù)csv里面有多少行來決定打開多少個標(biāo)簽頁，并選擇使用await異步方式打開，然后根據(jù)讀到的authCode，去進(jìn)行下一步生成的session_token進(jìn)行代碼編寫，再進(jìn)行await page.goto(url)，根據(jù)功能特性進(jìn)行操作步驟，另外場景二需要多人進(jìn)入一個會議室，客戶端策略是每個人都默認(rèn)展示第一屏， 相應(yīng)的增加了會議中翻頁的功能，并根據(jù)await div_locator.count()數(shù)進(jìn)行循環(huán)翻頁，用的是協(xié)程，只有等上一個標(biāo)簽頁面完成了所有程序后才能進(jìn)行下一個標(biāo)簽頁面，只要算出當(dāng)前標(biāo)簽頁最多能點(diǎn)多少次就好了，之后再進(jìn)入的人不會影響上一個標(biāo)簽頁，從而上一個標(biāo)簽頁也不會再繼續(xù)翻頁了，這樣就解決了使用同一份代碼，不同人進(jìn)入會議后都在不同頁碼的問題，這樣就能遍歷到所有的翻頁，也就是說如果有30個人進(jìn)入會議，分別在1-5的屏上。

但是后來發(fā)現(xiàn)rtc當(dāng)中經(jīng)常的斷開重連后又默認(rèn)展示第一頁，又改變策略為共享屏幕，繼續(xù)修改代碼。



在調(diào)試的時候，會經(jīng)常出現(xiàn)超時的問題



后來在goto url里面增加timeout=10000000的參數(shù)，解決了該問題。

awaitpage.goto(url,timeout=10000000)

測試實(shí)施

好了，本地的測試代碼調(diào)試通過了，服務(wù)端也準(zhǔn)備就緒。但是，那么多的發(fā)壓真實(shí)設(shè)備怎么來，讓同事全部使用自己的電腦？那肯定是不夠的也不現(xiàn)實(shí)的，因?yàn)榉?wù)端做了一些策略限制，比如不管會議室里面多少人，只有第一頁的人有流量，這是為了節(jié)約成本。

另外playwright虛擬瀏覽器也是非常消耗資的，瀏覽器需要運(yùn)行多個解碼器，本身也是一種負(fù)擔(dān)，所以一臺測試機(jī)上不能開太多標(biāo)簽頁，使用了一下，8G內(nèi)存的測試機(jī)開4個標(biāo)簽頁，也就是4個webrtc連接；20G內(nèi)存的測試機(jī)開7個webrtc連接，基本測試機(jī)的CPU使用就已經(jīng)是100%了。

使用基于云的解決方案意味著，那還得花時間去寫一份移動端的代碼，而且移動端的兼容性代碼需要花更多時間，另外移動網(wǎng)絡(luò)和設(shè)備會如何影響你的基礎(chǔ)設(shè)施，此方案排除。雖然也可是申請?zhí)摂M機(jī)，但是還是想看到各個測試機(jī)真實(shí)的流狀態(tài)，最后決定通過公司內(nèi)部申請Windows測試機(jī)做為壓測機(jī)器。

比較好的準(zhǔn)備工作如下：

①.測試機(jī)器：環(huán)境準(zhǔn)備，為了快速的讓IT人員準(zhǔn)備機(jī)器，大概50-60臺， 我們先把需要的測試工具，測試腳本和腳本依賴環(huán)境requirements文件都給IT人員，讓IT人員先統(tǒng)一的幫忙安裝好系統(tǒng)的同時幫助我們安裝好我們需要的軟件環(huán)境。

②.測試準(zhǔn)入：需要申請的一些特殊網(wǎng)絡(luò)準(zhǔn)入，也讓IT人員做好MAC地址的記錄，拿到list后統(tǒng)一一次性申請。

③.測試網(wǎng)絡(luò)：申請交換機(jī)，準(zhǔn)備好網(wǎng)線。

④.測試同步：因?yàn)闇y試機(jī)很多，每個單獨(dú)運(yùn)行腳本也是非常耗時的，開始的時候調(diào)研想過使用Playwright Grid進(jìn)行分布式測試，Playwright Grid的原理就不過多的說，大概就是可以在遠(yuǎn)程機(jī)器上啟動瀏覽器,實(shí)現(xiàn)多臺設(shè)備同時運(yùn)行測試。

這可以加快測試時間,模擬真實(shí)用戶環(huán)等，其中步驟里面有一句：測試腳本直接運(yùn)行在Grid服務(wù)器上,使用與本地Playwright一致的API,不需要修改代碼。實(shí)際中是我們每臺機(jī)器的代碼都有不一樣的地方，比如authCode或者要進(jìn)入的會議號都不一樣等，所以就放棄了Grid的方案。

壓力測試下的共同功能驗(yàn)證體驗(yàn)測試 部分主觀感受指標(biāo)，當(dāng)著參考。

1.視頻：

5分：完美。畫面十分清晰流暢

4分：好。畫面有輕微的不清晰、輕微的降幀，仔細(xì)看能看的出來，但感覺還算流暢

3分：中。偶有卡頓、或者畫面不清晰，但是還能接受

2分：差。頻繁卡頓，但是還算可用

1分：不可接受。完全卡住，或者畫面不可辨，完全不可用

2.音頻：

5分：完美。聲音清晰、流暢（與打移動電話體驗(yàn)一致）

4分：好。音質(zhì)不錯，雖然不完美，但不影響交流

3分：中。音質(zhì)一般（有卡頓、吞字、不清晰、聲音忽小忽大），但湊合也能用

2分：差。經(jīng)常聽不清楚，影響交流

1分：不可接受。完全聽不清楚對方說什么

問題記錄和調(diào)優(yōu)

webrtc服務(wù)端環(huán)境，服務(wù)端使用集群方式部署的，有不同城市的服務(wù)器，本次壓力測試的目標(biāo)不是壓測集群的壓力極限， 而是看在300路webrtc連接壓力下，同時房間管理，多人通話是否正常，資源使用是否合理，調(diào)度是否合理等。

本次壓力測試，肯定是在客戶端和服務(wù)端聯(lián)調(diào)完成后，能正常工作，并且該解決的p0,p1級問題之后才進(jìn)行，要不當(dāng)中很多問題會影響壓力測試進(jìn)度。當(dāng)然我們更需要知道在一定壓力下，邀請相關(guān)人員加入一起體驗(yàn)測試功能，發(fā)現(xiàn)更多的問題也是目標(biāo)之一。

測試中途發(fā)現(xiàn)重要問題：

服務(wù)端：1.IP調(diào)度不準(zhǔn)確。2.內(nèi)存使用過高。3.內(nèi)存存在泄漏，回不到原點(diǎn)。

客戶端：1.客戶端經(jīng)常掉線或者rtc斷開重連等。2.一個會議室達(dá)到一定人數(shù)后就會自動鎖會，再往里面加入就非常困難了， 經(jīng)常收不到入會請求 ，不知道是客戶端沒有發(fā)出去還是主持人沒有收到請求，收不到準(zhǔn)入客戶端就入不了會，腳本就超時失敗了。

典型問題調(diào)優(yōu)過程： 內(nèi)存無法回到原點(diǎn)的問題，服務(wù)端排查找原因，sfu內(nèi)存回收慢的問題，是linux 運(yùn)行時內(nèi)存控制方式不同導(dǎo)致，那調(diào)研l(wèi)inux內(nèi)存管理方式，切ptmalloc到tcmalloc，適時手動操作內(nèi)存釋放。 客戶端rtc斷開重連問題，

①.開始的時候，房間管理頻繁斷開，排查發(fā)現(xiàn)并發(fā)接收消息有問題，服務(wù)端修改并發(fā)接收結(jié)構(gòu)，并且改大超時時間為10秒；另外客戶端增加房間管理重連重試機(jī)制；

②.測試一段時間又出現(xiàn)房間管理連接斷開，重連后狀態(tài)不同步。解決辦法就是連上websocket就發(fā)消息，修改保證連上websocket并加入房間才發(fā)送消息；③.解決后發(fā)現(xiàn)網(wǎng)絡(luò)穩(wěn)定的時候，房間管理的長連也有頻繁斷開情況。解決辦法就是連上websocket就發(fā)消息，修改保證連上websocket并加入房間才發(fā)送消息。

壓測中記錄好問題產(chǎn)生的原因和解決方法，然后繼續(xù)調(diào)優(yōu)驗(yàn)證直到服務(wù)端資源使用符合預(yù)期為止。其他的問題有的作為已知問題待解決。

測試報(bào)告

測試報(bào)告里面包含三部分，測試結(jié)論，資源使用情況，主要功能驗(yàn)證情況，以及測試當(dāng)中發(fā)現(xiàn)的問題分析。

測試結(jié)論：300路連接并發(fā)下，可以較好地支持碼流為xxxkbps的碼流300路對等鏈接，太具體的詳細(xì)數(shù)據(jù)不便于寫出。

資源使用包括：用戶連接數(shù)，RTC流數(shù)量，CPU使用率，服務(wù)器實(shí)時碼率，服務(wù)器消耗流量，內(nèi)存使用，截取趨勢圖展示。檢查服務(wù)器資源是否是線性的。

功能驗(yàn)證包括：各種場景的主觀感受均值，掉線次數(shù)等等，生成一個excel表記錄。

測試發(fā)現(xiàn)問題：測試當(dāng)中發(fā)現(xiàn)的問題經(jīng)過服務(wù)端客戶端同事的多次排查，需要解決集群的資源，客戶端問題，寫上發(fā)生的原因，以及解決方法等。

以上，為本次webRTC壓力測試的一些方案過程和心得，希望對大家的日常工作能有所幫助。







審核編輯：劉清