如果你允许多人加入WebRTC通话，你可能会以SFU结束。计划如何分配容量比较困难-通常会进行估计，SFU应该放在哪里，它们将会消耗多少带宽，你需要何种服务器。
为了帮助网络架构和WebRTC工程师作出决定，Alex博士和他的CoSMo Softwae团队将负载测试元件放在一起来测量负载和视频质量。他们公布了所有主流的开源WebRTC SFU的测试结果。这个元件基于KITE并且在webrtc.org上用来显示互通状态。CoSMo团队还开发了一个基于机器学习的视频质量评估框架来优化实时交流。
首先注意：问哪种SFU是最好的就相当于问哪种汽车是最好的。如果你只要求速度快，那你应该买F1赛车，但是它不能帮助你送孩子上学。供应商从来不会对这些测试感兴趣因为它将它们的功能仅仅总结成一些性能指标。这些指标可能在它们的测试中不起主要作用，并且也不是判别产品好坏的主要标准。对于WebRTC SFU,仅仅因为SFU可以负载许多流，但是可能还有别的限制条件，用户行为，花费优化等原因使得他们不能这样做。负载测试同样不会深究用户体验，开发难度，或其它对服务的成功有帮助的部分。
当建立花费模型时，有很多情况我本人都想获得数据。Alex和他的团队已经做了很多深度工作，这是WebRTC开源生态系统逐渐成熟的一个好的象征。这个测试并不完美，但是我相信它会对WebRTC社群具有参考价值。
介绍
一个 discuss-webrtc mailing list 上经常被提到的问题就是什么是最好的SFU。这将会从各种SFU供应商和团队中得到‘很明显我的最好’的回答。很明显，他们不可能同时都是最好的。
你可以在这里查看论坛, Chad Hart提出了问题所在并且表示我们需要：
在任何情况，我认为我们都需要一个全球的可重复的并且不偏袒的基准，对于一些扩展性的指标。
三年之后，我和我的团队已经建立了这样一个基准系统。我将会解释这个系统如何工作展示我们的初步结果。
问题
许多SFU供应商都提供负载测试工具。Janus 有 Jattack. Jitsi 有 jitsi-hammer ，甚至公布了他们的结果。Jitsi对于数据的透明度做得最好并且提供了可靠的数据，和足够的信息来重复得到同样的结果。然而，不是所有的供应商具备这些工具。另外，每个工具都被设计出来回答不同的问题，例如：
一个给定类型和带宽的单一服务器可以处理多少流？
同时可以支持多少用户？
一个会议可以支持多少用户？
等等……
因此不存在一个公平的比较方式。我们希望产生一些可以被同行评审的结果，人们不必被迫接受它。
使用情形是什么？
为了得到一个什么是最好的SFU的好回答，你需要解释你用SFU来做什么。
我们选择研究两种人们最关注的使用情形，至少它们被讨论的最多，产生的拥堵最多。
- 视频会议：多对多
- 媒体流：一对多，单一方向的。
多数视频会议问题关注单一服务器。对于大多数人来说，一个视频会议中有20人以上参加可以被认为人数很多。像这种研究表明在大多数情况下大多数的通话是1对1通话，并且平均参与人数是3人。这种情况通过公共云服务提供商的一个小的服务器就可以解决（只要你得到1Gbps的NIC）。接着你可以使用非常简单的负载平衡和水平扩展技术，因为发送者和接受者的人数比例并不高。另一方面，媒体流，通常来自单一源头，并且发送至成千上万接受者。这需要多服务器等级制度。
我们想要容纳不同的测试情形，并且通过一些WebRTC服务器使用同样的形式实现它们，这样唯一的区别就是被测试的系统不同，因此结果就很公正，没有偏袒。
在本文中我将会集中讨论视频会议情形。如果你有兴趣，我们实现了媒体流测试，得到了结果，打算11月14日在Streaming Media West上发布。
测试元件
通过与Google和其它公司合作，我们开发了KITE，一个测试引擎，它允许我们支持任何形式的客户端—浏览器和原始移动端或桌面，轻松支持各种测试情形。在浏览器中每天都用它来测试WebRTC实现，就像你在webrtc.org上看到的那样。
选择一个测试客户端
负载测试通常使用单一客户端来完成。理论上来说在一台虚拟机上你可以并行的进行许多测试用例。因为这是WebRTC,所以使用浏览器是可以达到效果的。Edge 和Safari限制了单一进程，这使得它们不太适合做测试。另外，Safari只在MacOS或iOS上运行，也就是只在苹果机器上。如果你使用Windows或Linux,在AWS上建立数百万虚拟机相对更容易一些。如果安装百万台Macs,iPhones,或者iPads用来测试的话，难度和花费都会增大。
这就使得你需要使用Chrome或者Firefox浏览器，它们允许多个测试用例。我们的意见是使用Chrome更容易管理，我们可以处理更少的标签和插件，因此我们选择使用Chrome浏览器进行测试。
测试系统：
我们测试了这些SFU：
Janus
Jitsi
Kurento
mediasoup
Medooze
为了确保每个SFU的测试都产生了最好的结果，我们分别联系了这些团队。我们请求让他们安装服务器或连接服务器并且检查他们的设置。我们还分享了测试结果，这样他们就可以评论。他们确保了每个系统都达到了最佳的测试效果。
测试准备
我们使用了如下方法来增加负载。首先我们给每个视频会议房间每次增加一个用户，知道房间人数达到7人。我们重复这个过程，直到达到总目标用户人数。接近500个同时通话的用户。下图展示了测试床中的元素：
指标
当负载增加时，大多数关心扩展性问题的人将会测试CPU, RAM,和带宽。这是传统的做法，假设了流质量，和它们的比特率保持不变。
WebRTC的编码引擎将它变得更复杂。WebRTC包括了带宽评估，比特率调整和总体堵塞控制机制，人们不能假定流在实验过程中是保持不变的。除了通常的指标，测试人员还需要记录客户端指标，例如发送比特率，带宽评估结果，和延迟。关心视频质量同样重要。
在测试端，我们测量了以下参数：
成功和失败率
发送和接收比特率
延迟
视频质量
测量服务器端不同的指标非常简单，就像调用getStarts API。在我们的测试中，我们测试了：
CPU占用空间
RAM占用空间
入口和出口带宽的输入输出
流数量
还有一些不太相关的指标
上述指标由于空间限制，没有在Scientific article中发表，但是应该在接下来的研究报道中被发布。
所有这些指标都很容易产生，测量，除了视频质量这个指标。测量视频质量的目的是什么？一些代理，例如Google，提出了 render时间，接受帧，带宽使用等指标，但是它们却没有给出一个准确的测量。
原文标题：Breaking Point: WebRTC SFU Load Testing (Alex Gouaillard)
作者：‘Alex Gouaillard’
