1. 前言

????????不少網友最近私信我，咨詢webrtc sfu服務端性能問題，SRS開源服務能支持多少路webrtc流，mediasoup單房間能支持多少個人，推流能接入多少路，拉流能拉取多少路？720p能支持多少路，360p能支持多少路？

???????這里介紹一下如何測試webrtc sfu服務器的性能，介紹原理和實際操作。最后以srs和mediasoup兩個流行的webrtc sfu開源進行舉例，如何壓測其性能。

????????閱讀后，相信你今后能夠自己針對自己的視頻質量來進行對應的壓測。

2. whip和whep的出現

? ? ? ?webrtc雖然有一套標準協議族：信令sdp交互/stun/dtls/rtp/rtcp等，但是每個開源的sfu都有自己定義的信令交互方式。也就是信令的交互方式都是開源sfu自定義的，比如

• SRS(國內最流行的流媒體服務器之一)

  https post方式進行sdp交換

• MediaSoup

  websocket傳輸信令，信令把sdp進行拆分: 1)stun/dtls信息;2)音頻/視頻的rtp/rtcp信息；

????? 這個時候whip協議的規范出來，就提供了一個webrtc信令交互的標準。rfc已經有了draft文檔:?

https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html。

?????? whip全稱: WebRTC-HTTP ingestion protocol，也就是webrtc推流協議，有了這個協議，基本上就有了webrtc的推流標準，很多sfu的開源都支持該協議，客戶端OBS推流也支持該協議(可以用webrtc進行推流，來進行直播)

????? ?whep全稱: WebRTC-HTTP Egress Protocol，就是webrtc拉流協議，下行拉流協議。rfc的draf文檔地址:?

https://www.ietf.org/archive/id/draft-murillo-whep-03.txt。

????? ?本文主要就是基于whip/whep進行webrtc sfu壓測。

3. 基于cpp_streamer工具進行壓測

? ? ? ?cpp streamer是基于C++11開發的音視頻組件，使用者可以把組件串聯起來實現自己的流媒體功能。支持多種媒體格式，流媒體直播/rtc協議。

? ? ? ?網絡開發部分，采用高性能，跨平臺的libuv網絡異步庫。

? ? ? 支持webrtc的推流/拉流，并且代碼并未使用libwebrtc(chrome內部webrtc源碼，依賴較多，庫比較大)，而是筆者基于webrtc協議族規范(stun/dtls/rtp/rtcp等)開發的webrtc組件，代碼非常的輕量。

? ? ? ?下面介紹，如何使用cpp_streamer進行壓測。

4. SRS的webrtc性能壓測

? ? ? ?筆者推薦使用開源cpp_streamer進行webrtc壓測，下面介紹兩個方向的壓測:

• 推流壓測(whip)

• 拉流壓測(whep)

4.1?推流壓測

4.1.1?媒體源文件? ? ??

壓測的源文件采用mpegts格式，因為其能支持對opus音頻編碼的封裝，具體的要求:

• 視頻編碼

  H264,?profile必須是baseline；

• 音頻編碼

  Opus，采樣率48000，通道2

推薦使用ffmpeg生成媒體源文件:

ffmpeg -i src.mp4 -c:v libx264 -r 25 -g 100 -profile baseline -c:a libopus -ar 48000 -ac 2 -ab 32k -f mpegts webrtc.ts

用戶可以自己編碼制作自己想要測試的視頻分辨率，I幀間隔和幀率；

4.1.2?壓測

在linux服務器上編譯后，會生成whip_srs_bench執行文件，執行:

./whip_srs_bench -i webrtc.ts \-o "http://10.0.24.12:1985/rtc/v1/whip/?app=live&stream=1000" \-n 100

注意：

• -i的參數為測試源文件，mpegts格式，視頻H264 baseline profile，音頻opus且采樣率48000，通道數為2；

• -o的參數為srs的webrtc地址，地址要加引號，如10.0.24.12是srs的地址，1985是srs的信令http端口號

• -n為并發whip session個數，也就是推流的個數，推薦小于100，如果需要測試多于100的個數，推薦開啟多個whip_srs_bench命令行，以確保準確度

4.2 拉流壓測

在linux服務器上編譯后，會生成whep_srs_bench執行文件，執行:???????

./whep_srs_bench?\ -i?"http://10.0.8.5:1985/rtc/v1/whip-play/?app=live&stream=1000" \?-n?100

• -i的參數為srs的webrtc的whep拉流地址，地址要加引號，如10.0.8.5是srs的地址，1985是srs的信令http端口號

• -n為并發whep session個數，也就是拉流的個數，推薦小于100，如果需要測試多余100的個數，推薦開啟多個whep_srs_bench命令行，以確保準確度

5. Mediasoup性能壓測

5.1?推流壓測

????? ?壓測源文件如何生成，見4.1.1。注意：當前也僅僅支持H264+Opus的編碼格式。

在linux服務器上編譯后，會生成mediasoup_push_bench執行文件，執行:???????

./mediasoup_push_bench -i webrtc.ts \ -o "https://xxxxx.com:4443?roomId=200&userId=1000" \ -n 100

• -i的參數，webrtc.ts為源文件：mpegts格式，視頻h264 baseline；音頻opus 采樣率48000，通道數為2；

• -o的參數，mediasoup的broadcaster接入模式，xxxx.com:4443為sfu的域名地址，roomId為房間號，userId為用戶名。

• -n的參數為整數，測試并發的數量，推薦小于100，如果需要測試大于100的，開啟多個命令行，以保證拉流的準確度；

? ? ? ?mediasoup sfu的demo中，推流有個“坑”，注意：

? ? ? ?推流所在的roomId必須提前存在(也就是websocket端已經有人推流上來)，否則broadcaster創建失敗。如果需要房間Id不存在的前提下命令行推流能成功，需要修改mediasoup-demo的源碼server.js，如下:???????

expressApp.param(  'roomId', (req, res, next, roomId) =>??{??  queue.push(async?()?=>??????{??????  consumerReplicas?=?0;????????req.room?=?await?getOrCreateRoom({?roomId,?consumerReplicas?});????????next();??????}).catch((error)?=>??????  {????????  logger.error('room?creation?or?room?joining?failed:%o',?error);??????????reject(error);????????});  });

? ? ? ?原有代碼：在http api檢測roomId的房間是否存在，若不存在，拒絕創建broadcaster;

? ? ? 新代碼: 在http api檢測roomId的房間是否存在，若不存在，創建該roomId的新房間;

5.2 拉流壓測

在linux服務器上編譯后，會生成mediasoup_pull_bench執行文件，執行:???????

./mediasoup_pull_bench?\ -i?"https://xxxxx.com.cn:4443?roomId=100&apid=7689e48c-09ae-48ca-8973-ad5de69de5e8&vpid=aadbbb0b-2e4e-4ed8-8bd6-22e3c50b9fc1"?\?-n?100 \ -l?1.log

• -i的參數，mediasoup的broadcaster接入模式，xxxx.com:4443為sfu的域名地址，roomId為房間號，apid為推流audio的producerId, vpid為推流video的producerId；

• -n的參數為整數，測試并發的數量，推薦小于100，如果需要測試大于100的，開啟多個命令行，以保證拉流的準確度；

• -l的參數為日志文件(可選，如果不填寫，輸出到控制臺)