webrtc sfu 性能压测

不少网友最近私信我，咨询webrtc sfu服务端性能问题，SRS开源服务能支持多少路webrtc流，mediasoup单房间能支持多少个人，推流能接入多少路，拉流能拉取多少路？720p能支持多少路，360p能支持多少路？

作者：小新快跑
来源：音视频小话
原文：https://mp.weixin.qq.com/s/Dv3qWz5itI-6fjHgAl6gkQ

这里介绍一下如何测试webrtc sfu服务器的性能，介绍原理和实际操作。最后以srs和mediasoup两个流行的webrtc sfu开源进行举例，如何压测其性能。

阅读后，相信你今后能够自己针对自己的视频质量来进行对应的压测。

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压测。

基于cpp_streamer工具进行压测

cpp streamer是基于C++11开发的音视频组件，使用者可以把组件串联起来实现自己的流媒体功能。支持多种媒体格式，流媒体直播/rtc协议。

网络开发部分，采用高性能，跨平台的libuv网络异步库。

支持webrtc的推流/拉流，并且代码并未使用libwebrtc(chrome内部webrtc源码，依赖较多，库比较大)，而是笔者基于webrtc协议族规范(stun/dtls/rtp/rtcp等)开发的webrtc组件，代码非常的轻量。

下面介绍，如何使用cpp_streamer进行压测。

SRS的webrtc性能压测

笔者推荐使用开源cpp_streamer进行webrtc压测，下面介绍两个方向的压测:

推流压测(whip)
拉流压测(whep)

推流压测

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帧间隔和帧率；

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命令行，以确保准确度

拉流压测

在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命令行，以确保准确度

Mediasoup性能压测

推流压测

压测源文件如何生成，见上文。注意：当前也仅仅支持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的新房间;

拉流压测

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