webrtc sfu性能压测

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交换

• MediaSoupwebsocket传输信令，信令把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的参数为日志文件(可选，如果不填写，输出到控制台)