作者：Tsahi Levent-Levi（原文连接）
翻译：刘通
原标题：How Many Users Can Fit in a WebRTC Call?
WebRTC通话中能有多少活跃用户？
这是一个比较难回答的问题。
如果你使用了MCU，只要MCU能处理的了，你就可以放入尽可能多的用户。
如果您使用的是SFU，则取决于3个不同的参数：
1. 媒体服务器的复杂程度以及它的性能
2. 客户端设备上可用的功率
3. 你构建的基础架构以及实现级联的方式
同样的场景，不同的实现
在一个有8到10个人的通话中，任何事情都会变得复杂。这里有一个我想分享的公开服务的例子：
这个场景中：
# 一个会话中有9名参与者
# 我使用testRTC让用户进入会话，所以这全部是自动的
# 我运行了1分钟。之后，因为它还是个demo所以会话终止了
# 它考虑到屏幕上有9个人，所以将所有人的分辨率降低到了VGA水平，但它为该分辨率分配了1.3Mbps
# 导致浏览器接收10Mbps的数据进行处理
媒体服务器决定了如何限制和衡量流量。
下面是另一个服务，它提供了一个运行完全相同场景的在线demo：
现在每个浏览器的平均输入速率仅为2.7Mbps，几乎是其他服务的四分之一。
同样的场景，不同的实现。
其他著名服务是怎么做的呢？
一些在SFU路由模型中进行视频会议的知名服务是怎么样的？它们对它们的应用程序有什么样的大小限制？
以下是我发现的：
# Google Hangouts：一个会话中最多存在25个参与者。之前是10个参与者。
# Hangouts Meet：一个会话中最多存在50名参与者。
# Houseparty：8名参与者。
# Skype：25名参与者。
# appear.in：它们的聊天室最多支持12名参与者。
# Amazon Chime：电脑版支持16个参与者，iOS版最多支持8名（暂时还不支持Android）
# Atlassian Stride和Meet Jitsi：50名参与者。
那这些是否意味着不能超过50名参与者呢？
我认为随着会议规模的增加，难度越来越大：
CPaaS对大小的限制
当你观察CPaaS平台时，那些支持视频和群组通话的服务通常会限制其会议规模。在大多数情况下，他们会给出一个他们测试过的或适合的数字。正如我们所看到的那样，这个数字适用于一个非常具体的情况，而这个情况可能与你设想的可能不一样。
在CPaaS中，这些数字在一个会话中从10位参与者到100位参与者不等。通常情况下，如果你想要更多的参与者的话，那么后加的人就只能保持“可见”状态。
需要记住的关键点
下面有几点需要你记住：
# 群组通话的规模越大，实现和优化就越复杂
# 浏览器需要运行多个解码器，这本身就是一种负担
# 在这种情况下，移动设备，特别是老旧设备，可能会很快崩溃。在确定要支持的群组大小之前，需要测试你计划支持的最老，最笨的设备是什么
# 你可以构建SFU，使其不会将所有传入媒体路由到每个人，而是选择部分数据发送出去。例如，音频通道上可能只有一个扬声器，或者是声音最大的4个音频流
调整你的媒体服务器
调整大小和媒体服务器是我最近在testRTC上做的事情。我在设计的每个其他项目中都会遇到这个问题：
我们可以将多少会话/用户/流添加到单个媒体服务器中？
根据我们上面看到的关于速度和馈送的内容，可以肯定地说，它确实取决于你在做什么。
如果你想要的是群组通话，其中每个人都是活跃的，你应该在一台服务器上目标设为100到500名参与者。这些数字将根据你为媒体服务器选择的计算机一级每个数据流平均计划的比特率而有所不同。
如果你想要的是一个单人广播给更多的观众，所有通过WebRTC完成以保持低延迟，那么200到1000人可能是一个比较合适的估计值，也许更多。
大型机器还是小型机器？
你需要解决的另一件事是你要将哪台机器作为你的媒体服务器。是你可用的最大的机器吗？还是你会对较小的机器感到满意？
大型机器意味着你可以将更多的观众和会话塞进一台机器中，因此你的服务复杂性会更低。如果发生崩溃（媒体服务器崩溃），更多用户将会受到影响。当你需要升级你的媒体服务器时，这个过程会让你付出更多的代价，或者变得更加复杂。
机器越大，它的内核就越多。这导致媒体服务器要以多线程模式运行。这也意味着它们的构建，调试和修复会变得更加复杂。
用小型机器意味着你会更早地遇到规模问题，它们将需要更精细的算法和启发式算法。你会由于负载平衡服务的方式而遇到更多的边缘情况。
规模是基于流，带宽还是CPU？
你如何确定你的媒体服务器达到了满负荷？你如何决定下一个会话是否要塞进一台新机器或者另一个机器，还是放置在当前使用的媒体服务器上？如果你要使用当前这个，并且新参与者想要加入在此媒体服务器上正在运行的会话，那么他们是否有足够的空间？
这不是一个容易回答的问题。
我看到过3种不同的度量标准用语决定何时从单个媒体服务器向其他媒体服务器扩展。以下是一般选择：
基于CPU：当CPU占比达到一定程度时，就意味着机器已经满了。当你使用较小的机器时，这种度量标准效果最好，因为CPU会成为你消耗的第一批资源之一。
基于带宽：SFU会消耗大量的网络资源。如果你使用的是更大的机器，你可能不会达到CPU的限制，但你最终会占用掉太多的带宽。所以你最终会通过带宽监控来确定可用的容量。
基于流：有时使用CPU和带宽作为衡量标准的挑战在于，根据动态条件，可支持的会话和数据流的数量可能会有所不同。你的扩展策略可能无法应对，你可能需要更多的计算控制权。这将导致你使用CPU或者带宽来调整机器的大小，但会根据服务器可支持的数据流数量来制定限制规则。
这里需要面对真正的挑战是，无论你选择哪种方案，调整大小都是你需要独自完成的事。
