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

Webrtc壓測(cè)主要問(wèn)題：

1.那么多的壓力客戶端從哪里來(lái)？

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

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

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



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

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

編寫webrtc壓力客戶端代碼

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

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

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

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

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

具體Webrtc核心測(cè)試代碼：



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

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

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



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



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

awaitpage.goto(url,timeout=10000000)

測(cè)試實(shí)施

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

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

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

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

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

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

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

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

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

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

1.視頻：

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

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

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

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

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

2.音頻：

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

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

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

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

1分：不可接受。完全聽不清楚對(duì)方說(shuō)什么

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

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

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

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

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

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

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

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

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

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

測(cè)試報(bào)告

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

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

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

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

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

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







審核編輯：劉清