选择测试客户端
负载测试通常由单个客户端完成，以便控制客户端的影响。理想情况下，你可以在单个虚拟机（VM）中并行运行测试客户端的许多实例。由于我们使用WebRTC，所以可以使用上述中的任一种浏览器。但是Edge和Safari只能运行一个实例，所以它们不是很适合用作测试。此外，Safari只能运行Apple硬件驱动的MacOS或iOS。如果你运行的是Windows或Linux，那么在AWS上生成一百万个VM相对容易些。而使用一百万台Mac、iPhone或iPad进行测试就要困难得多，成本也很高（尽管如此，我仍然有这样的设想）。
剩下能用的浏览器就是Chrome或Firefox，它们能很好地运行多个实例。我们认为，Chrome浏览器的网络驱动程序更易于管理，并且要处理的标记和插件（即H264）更少，因此我们选择使用Chrome浏览器。
测试系统
我们测试了以下SFU：
为了确保每个SFU都能发挥其最佳状态，我们联系了每个项目背后的团队，并提议让他们自己设置服务器或连接到服务器、检查其设置。我们还同他们分享了结果，以便他们发表评论。这样可以确保我们正确配置每个系统，以使其在测试中达到最佳状态。
有趣的是，在本研究此次我们发现了一些错误，并与各个团队合作，改进其解决方案。我们会在文章最后一部分对此进行更详细的讨论。
测试设置
我们使用这样的方法将流量添加到高负载中：首先，我们在每个视频会议室中采取一次一位的方式来添加用户，直到每个房间里有7个用户。重复此过程，直到同时在线的用户总数达到近500人。
测试平台由如下元素组成：
指标
当“负载”（即流、用户、房间等等）增加时，对可伸缩性感兴趣的大多数人会查看服务器的CPU、RAM和带宽占用量。这是一种传统的处理方式，那就是假设流的质量、比特率等都保持不变。
WebRTC的编码引擎使这一过程变得更加复杂。WebRTC中包括带宽估计、比特率自适应和整体拥塞控制机制，所以它无法假设流在整个实验过程中保持不变。除了通常的一些指标外，测试人员还需要记录客户端指标，例如发送的比特率、带宽估计结果和延迟。监测视频质量也很重要，因为在你饱和服务器的CPU、RAM和/或带宽之前，视频质量可能会下降。
在客户端，我们最终实行了以下测量项目：
成功率和失败率（视频卡顿或无视频）；
发送端和接收段的比特率；
延迟；
视频质量（下一节中有更多介绍）；
在服务器端测量不同指标很容易，和你自己汇总getStats API或集成诸如callstats.io之类的解决方案一样简单。在我们的案例中，我们测量了：
CPU占用空间；
RAM占用空间；
进出带宽；
流的数量；
其他不太相关的指标。
由于篇幅所限，以上指标未在《科学》杂志上发表，但会在随后的研究报告中发布。
除视频质量外，所有这些指标都易于生成和测量。那么衡量视频质量的客观指标是什么呢？确实有一些监测视频质量的指标，比如Google渲染时间、接收到的帧、带宽使用情况等。但是这些都不能提供准确的测量结果。
视频质量指标
理想情况下，在出现障碍时，我们可以很容易监测视频质量。这使大家能够测量弹性技术的相对优势，例如可伸缩视频编码（SVC）。从概念上讲，与其他编码方法相比，用SVC输出视频与抖动、数据包丢失等障碍原因关联不大。参阅以下来自Agora的视频，你可以更好地理解视觉比较：
https://www.youtube.com/watch?v=M71uov3OMfk
在快速研究这种测量视觉质量的自动化方法之后，我们意识到不可能开发出一种在没有实时流参考媒体时，像人那样精准评估视频质量的方法。因此，我们继续利用神经网络的机器学习来优化衡量标准。这样就可以进行实时的视频质量评估。另外，无需录制客户媒体即可使用它，避免了触犯法律或侵犯隐私等问题。
本文中不会详述这种机制的细节。你可以点击这里，阅读更多有关视频质量算法的信息。这个基于AI的算法的详细信息已提交发布申请。只要申请通过，我们就会公开它。
测试结果
我们用从各团队的公共GitHub存储库中下载的最新源代码（Kurento / OpenVidu除外，因为使用了Docker container）设置了以下五个开源的WebRTC SFU：
Jitsi Meet（JVB版本0.1.1077）；
Janus Gateway（0.4.3版）及其视频室插件；
Kurento（来自OpenVidu Docker container，Kurento Media Server版本6.7.0）；
mediasoup（版本2.2.3）。
每一项都配有单独虚拟机，但设置相同，有默认配置。
→ 相关阅读：WebRTC 通话质量调优必备：三个弱网模拟测试工具
文章地址：https://webrtchacks.com/sfu-load-testing/
原文作者：Alex Gouaillard
