最近幾年WebRTC特別火，但如何對WebRTC服務進行壓力測試是一個很有難度和挑戰的工作，因為WebRTC客戶端實際使用上產生的壓力瓶頸主要來源對象是碼流而非傳統的HTTP并發請求。因為業務要求服務至少能支持提供300路并發，于是準備300路WebRTC連接驗證下SFU服務器壓力情況，這里分享進行壓測的思路及方式和一些的經驗，如果在這方面有相關經驗的測試技術方案的測試同行，請加評論給予指導幫助。

Webrtc壓測主要問題：

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

2.如何監控服務器性能？

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

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



我們搞清楚系統框架后，為實現壓力測試目標，需要使用具備以下幾點的自動化工具：

◆穩定且可預測的設備及運行網絡；
◆能在不同條件下進行測試，可動態控制的可配置網絡；
◆可以測試來自不同地點的用戶；
◆對結果進行詳細的可視化分析，以方便理解測試結果。 接下來走入正題，開始進入測試工作。

編寫webrtc壓力客戶端代碼

因為團隊想看到實際壓測中的全鏈路表現，比如房間管理，分散均勻的進入不同會議室，和多人進入一個會議室通話情況等。

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

它基于Websocket協議，可以接受瀏覽器（服務端）的信號。

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

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

具體Webrtc核心測試代碼：



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

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

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



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

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"

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

但是后來發現rtc當中經常的斷開重連后又默認展示第一頁，又改變策略為共享屏幕，繼續修改代碼。



在調試的時候，會經常出現超時的問題



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

awaitpage.goto(url,timeout=10000000)

測試實施

好了，本地的測試代碼調試通過了，服務端也準備就緒。但是，那么多的發壓真實設備怎么來，讓同事全部使用自己的電腦？那肯定是不夠的也不現實的，因為服務端做了一些策略限制，比如不管會議室里面多少人，只有第一頁的人有流量，這是為了節約成本。

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

使用基于云的解決方案意味著，那還得花時間去寫一份移動端的代碼，而且移動端的兼容性代碼需要花更多時間，另外移動網絡和設備會如何影響你的基礎設施，此方案排除。雖然也可是申請虛擬機，但是還是想看到各個測試機真實的流狀態，最后決定通過公司內部申請Windows測試機做為壓測機器。

比較好的準備工作如下：

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

②.測試準入：需要申請的一些特殊網絡準入，也讓IT人員做好MAC地址的記錄，拿到list后統一一次性申請。

③.測試網絡：申請交換機，準備好網線。

④.測試同步：因為測試機很多，每個單獨運行腳本也是非常耗時的，開始的時候調研想過使用Playwright Grid進行分布式測試，Playwright Grid的原理就不過多的說，大概就是可以在遠程機器上啟動瀏覽器,實現多臺設備同時運行測試。

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

壓力測試下的共同功能驗證體驗測試 部分主觀感受指標，當著參考。

1.視頻：

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

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

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

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

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

2.音頻：

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

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

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

2分：差。經常聽不清楚，影響交流

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

問題記錄和調優

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

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

測試中途發現重要問題：

服務端：1.IP調度不準確。2.內存使用過高。3.內存存在泄漏，回不到原點。

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

典型問題調優過程： 內存無法回到原點的問題，服務端排查找原因，sfu內存回收慢的問題，是linux 運行時內存控制方式不同導致，那調研linux內存管理方式，切ptmalloc到tcmalloc，適時手動操作內存釋放。 客戶端rtc斷開重連問題，

①.開始的時候，房間管理頻繁斷開，排查發現并發接收消息有問題，服務端修改并發接收結構，并且改大超時時間為10秒；另外客戶端增加房間管理重連重試機制；

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

壓測中記錄好問題產生的原因和解決方法，然后繼續調優驗證直到服務端資源使用符合預期為止。其他的問題有的作為已知問題待解決。

測試報告

測試報告里面包含三部分，測試結論，資源使用情況，主要功能驗證情況，以及測試當中發現的問題分析。

測試結論：300路連接并發下，可以較好地支持碼流為xxxkbps的碼流300路對等鏈接，太具體的詳細數據不便于寫出。

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

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

測試發現問題：測試當中發現的問題經過服務端客戶端同事的多次排查，需要解決集群的資源，客戶端問題，寫上發生的原因，以及解決方法等。

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







審核編輯：劉清