Jitsi Videobridge 性能评估

原文链接：https://jitsi.org/Projects/JitsiVideobridgePerformance

如果你打算使用Jitsi Videobridge或者任一种SFU, 首先想到的问题是它处理负载的性能怎么样. 毕竟性能和花费是选择视频混合器(MCU)的主要因素.

如果你认为MCU带给你不好的体验时, Jitsi Videobridge将满足你的需求.

先看一下所有结果中有代表性的总结:

在一台花费大约100美元租用的Xeon 服务器上, 运行1000以上的视频流仅需要20%的CPU, 平均用550 Mbps.

1、 测试平台

所有的测试均运行在安装Jitsi Meet的专用服务器上. 这个服务器运行了Jitsi Meet需要的所有服务： 一个web服务器(nginx),一个XMPP服务器(prosody) 和 Jitsi Videobridge。这个服务器配置了四核Intel ® Xeon® E5-1620 v2 @ 3.70GHz CPU。

在测试中，我们每秒测一次如下变量：

• conferences –活跃的会议数量。
• endpoints – 在所有的会议中，产生负载的端点数目。
• cpu_usage – 最近期间的CPU (所有核)的负荷。通过CPU的以下指标来衡量：用户,系统, Nice, IOWait (这些在top(1)中以“%Cpu(s)”显示)。
• network_in – 接收的比特率，通过ifstat以两秒的间隔测得。
• network_out – 发送的比特率。

下述变量从以上变量中提取：

• bitrate -- network_in和network_out的总和, 转换成Mbps (每秒10^6 bits)。
• streams –Jitsi Videobridge发送的音视频流的总和. 这个与conferences, endpoints和其它因素有关(不发送数据的endpoints)。

测试中，我们运行了一个Jitsi Meet会议，测试随着endpoints的数目（K）增长的情况。我们使用一个Chrome实例，运行实际的Jitsi Meet应用并提供“focus”的会议服务。第一个endpoint 用相机和静音的麦克风。其余的K-1个endpoints我们使用Jitsi Hammer实例。每一个流，即之前记录的音视频文件合成了平均每个endpoint 515 Kbps的比特率。

 

2、 一个测试场景的样本

  使用浏览器来满足会议的数目需要占用成千上万台机器，这不是明智的选择。

我们创建一个会议采用full-star拓扑结构，从每一个endpoint传入的流量将分发到其余任一个连接到Jitsi Videobridge的endpoint上。在这种配置下，有K*(K-1)个流离开videobridge （k-1个流进入）。

我们测试在不同endpoints数目时的情况，即k= 10,15, 20, 25, 29和33时。

视频流的数目随产生负载的endpoints的数目呈二次型增长，因为每一个endpoint从其它端得到的流需要加密和传输。

在一个拥有成百上千的参与者的会议中，没有人愿意立刻看到所有人。首先，这样的话不方便。

其次，它要求用户有大量的下载带宽。一般来说，在大规模部署会议中，人们想要用JitsiVideobridge的最近N模式，即只有最近经常发布的报告人的视频才会列出和展示。

这里我们的目的是产生负载，所以流的数目和比特率才是真正关心的部分。一旦流的数目确定，不需要关心发送给endpoints的数目。也就是说，无论是1000个endpoints每个接收1个流，还是100个endpoints每个接收10个流，1000个视频流在CPU和带宽方面消耗一样。

3、  更详细的性能结果

下面的图显示了两次测试中CPU、比特率和视频流（或是音视频流）的数目结果。

在这个测试中，我们使用33个发布者并且JitsiVideobridge产生1056个流（1056路音频和1056路视频），带宽使用超过了550Mbps。在上面的图表中，我们看到1056路流占用了大约20%的CPU。

在报告者的数目和流的数目不变时，我们计算平均比特率和CPU的占用率，结果如下图所示。本文最后将介绍全部细节。

由上图可知，CPU使用率和总的比特率呈近似线性增长。

虽然我们的测试使用的单会议，它有1056路视频流（音频流也一样）从videobridge流出。这种场景和528个点对点会议、176个3人组会议和53个5人组会议产生的比特率大致相等。

在我们的这些测试中没有特别呈现内存的消耗，因为Java虚拟机运行总是被限定在3GB内存上，并且它从来没有超出。事实上，在我们的测试中，前面ps(1)报道的Jitsi Videobridge处理的RSS从没有超过1500MB。

这些结果显示出JitsiVideobridge在处理较少资源的情况下，能够处理大量的比特率，并且分配均衡。

 

4、  更深入研究

下面的测试从10个报告者开始（90个流），然后按15，20，25增加，29个时有812路流。

下面放大的5个小图用来计算平均值（endpoints或者流保持不变的期间），可以看到在这些期间，CPU使用率比较稳定。