WebRTC压力测试：从客户那里学到的 6 件事

在过去的 8 年里，我一直在使用 testRTC 进行 WebRTC 测试和监控，我有机会从我们的客户那里学到很多东西。我想与您分享其中的一些经验，重点是WebRTC 压力测试。

1-WebRTC压力测试有不同的形式和规模

在开发WebRTC应用时，有一个时间点，你需要扩展该应用–确保它在更多的用户、更多的地点、以更多的方式运行。

在这一点上，你需要对你的WebRTC服务进行压力测试。

你需要问自己的是，到底什么是WebRTC压力测试？以下是我看到我们的客户对他们的WebRTC应用进行压力测试的几种方式：

• 弄清楚一次会议可以塞进多少个用户
  • 作为活跃的发言者
  • 流媒体或会议中的被动观看者
  • 打开相机

• 单个媒体服务器可以容纳多少用户和会话
  • 决定大小
  • 因为我们想要优化我们最终在云中使用的机器规格

• 横向扩展
  • 检查随着更多用户/房间加入服务，您在多个媒体服务器和信令服务器上对它们进行负载平衡
  • 当您的服务针对位置进行优化，将用户连接到最近的媒体服务器时，查看来自多个地区的用户加入单个会话时会发生什么

• 每秒注册数，每秒调用数，……
  • 当许多用户在同一秒内加入该服务时会发生什么情况？他们都成功了吗？有的连接不上？
  • 找出您正确支持的 CPS（每秒调用数）

• 浸泡测试
  • 如果我们长时间加载服务——会发生什么？
  • 我们观察到崩溃吗？内存泄漏？延迟增加？

• 端到端
  • 同时对 Web 服务器、API 服务器、信令服务器和媒体服务器进行压力处理
  • 达到我们希望在整个服务中提供的最大容量

不同的开发人员以截然不同的方式看待和理解压力。哪些适用于你？

2–以可预测和可重复的方式赢得胜利

可预测和可重复意味着如果我多次运行相同的测试场景，我希望得到大致相同的结果并体验相同的行为。

WebRTC 是一个复杂的野兽。它依赖于很多移动部分：位置、网络性能、连接性等。让所有这些都保持一致和静态以重复执行测试场景很重要。

为什么这很重要？这样开发人员就可以运行和调试 QA 报告的失败测试的相同测试场景。一旦错误被修复，QA 就可以运行完全相同的测试来验证修复。

它还使您能够优化应用程序的性能，然后运行相同的测试场景以查看优化工作是否改善了我们的预期。

可重复的bug是黄金。它们几乎邀请你去解决它们，因为它们没有藏在任何地方。你能使可重复的错误越多，对你和你的开发者来说就越好。当我们在做这件事的时候，有一个测试基础设施，使尽可能多的移动变量成为静态，意味着你的更多测试将是可预测和可重复的。

3–从树木中看到森林

使用 100 种浏览器运行大型测试？伟大的！

你如何处理结果？您是否从一个 webrtc-internals 转储文件转到下一个以弄清楚每个浏览器在该测试中的表现如何？

有这么多树（=浏览器），你如何看待森林（测试场景结果）？

以下是参观森林所需的一些条件：

• 聚合指标分析——平均或求和
• 将浏览器结果的失败和警告传播到总测试结果

使用 WebRTC，我们不仅仅对浏览器性能指标感兴趣。我们对 WebRTC 指标数据及其聚合分析感兴趣。

4–看清森林中的树木

相反的情况同样重要。一旦获得测试结果并查看了聚合数据，就必须能够查看特定的树（=浏览器）。

这里有两点很重要：

1. 能够轻松查明哪个浏览器存在任何 WebRTC“波动”——不应该发生的事情，例如高丢包率、断开连接、高延迟或普通故障
2. 向下钻取功能，以便您可以分析单个浏览器及其拥有的 WebRTC 对等连接

如果没有简单的方法来理解和查明大型测试中的罪魁祸首，那么您将浪费大量时间来寻找它。

5–小测试，大结果

大型测试是有代价的：

1. 他们使用更多的资源，所以他们花费更多
2. 他们需要更长的时间来计划、运行和分析

在许多情况下，您应该追求的是一种最小可行测试（有人知道 MVT 吗？）

我在这里的意思是，您希望能够在不运行太大的测试的情况下找到尽可能多的错误。根据经验，您会在 1,000 个或更多浏览器中发现的大多数错误都可以在 100 或 200 个浏览器中发现，而这些浏览器仅针对计划用于生产的单个服务器单元。

这并不是说您不应该运行较大的测试——只是您应该首先尝试从较小的 WebRTC 压力测试中获得最大收益。这样，您将能够更快地清理和修复您的 WebRTC 应用程序，同时浪费更少的时间。准备就绪后，您可以继续进行下一组更大的压力测试。

每次都运行大型测试很好，但最终会在失败中出现大量误报，并且需要查看过多的日志数据以查找在较小的测试运行中更容易发现的错误。

我的建议？以逐步推进压力测试为目标：征服 10 个并发浏览器。然后移动到 50 或 100。从那里，200-500。然后瞄准你想要更大的地方。

6–更短的周期 = 更低的总成本

这就是这一切的症结所在。我们正在尝试做的是减少我们的 WebRTC 开发周期。更短的周期意味着更快的开发。

如果您正在进行压力测试，那么您将陷入痛苦的世界：

• 事情可能会以不同的方式破裂
• 需要修改测试脚本以适应您的基础架构在负载下的行为
• 信令或媒体服务器可能会失败，需要修复
• 服务器配置需要微调
• 可能需要重新审视网络容量和路线
• ETC

在 WebRTC 压力测试过程中，有太多的东西会破坏。

要想脱颖而出并高效地完成这一过程，最好以缩短测试周期和快速迭代为目标。正如我已经说过的，更大的测试需要更多的时间和资源。

这意味着运行旨在进行压力测试的较小测试，然后随着我们在测试计划中的进展而增加测试规模意味着您可以加快迭代速度。你迭代得越快，你就能越快地解决问题并质疑你看到的结果，帮助你进入 WebRTC 压力测试项目的下一阶段。

从哪儿开始？

开发 WebRTC 应用程序？

从第一天开始就提前考虑并计划您的压力测试：

• 决定你是想在内部构建整个测试平台还是使用第三方（如果你正在寻找一个，我知道一个很棒的WebRTC 测试供应商）
• 确定您最感兴趣的比例和参数（您可以在进行时更改它们，但最好有一些指导方针作为开始）
• 旨在进行有效测试以缩短您的开发周期并支持更快的迭代

即使您最终没有使用我们的testingRTC 产品，我也邀请您与我们联系。您将站在我们的专家面前，学习一两件事，这肯定会帮助您走上通往 WebRTC 成功的道路。

作者：Tsahi Levent-Levi
原文链接：https://www.spearline.com/blog/6-things-i-learned-from-our-webrtc-stress-testing-customers/