原文链接: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使用率比较稳定。