第24章压力测试

课程目录第24章压力测试

24、压力测试：使用 KITE 框架进行大规模 WebRTC 压力测试，分析服务器承载能力

说到 WebRTC 的压力测试，很多人第一反应是「开几十个浏览器窗口，然后看服务器挂不挂」。嗯，我当年也这么干过。结果呢？手动点开 20 个标签页，机器直接卡死，测试数据还乱七八糟的。

后来我接触到 KITE 框架，才算是找到了正路。说白了，KITE 就是专门为 WebRTC 设计的自动化测试框架。它帮你管理多个浏览器实例，模拟真实的通话场景，还能收集各种性能指标。

我个人习惯，每次做大规模压力测试前，都会先问自己三个问题：

我的服务器到底能撑多少路并发通话？
CPU、内存、带宽，哪个先扛不住？
丢包率、延迟、抖动，在什么阈值下用户会骂娘？

KITE 框架就是用来回答这些问题的。咱们一步步来看。

KITE 框架的核心架构

KITE 不是一个大而全的怪物，它由几个模块组成，各司其职。我画了张图，帮你快速理解它的工作流程。

你看，KITE 控制节点是大脑，它负责调度测试用例、启动浏览器实例、收集指标。浏览器实例就是你的「虚拟用户」，它们会按照测试用例的脚本，建立 PeerConnection、收发音视频流。指标收集模块则负责抓取各种数据，比如 CPU 使用率、内存占用、丢包率、RTT 等等。

我曾经在项目中遇到过一个坑：测试脚本写得太复杂，导致浏览器实例启动后光执行脚本就花了 10 秒，真正的通话时间反而很短。后来我学乖了，把脚本精简到极致，只保留核心的建连和收流逻辑。

搭建 KITE 测试环境

KITE 基于 Node.js，安装起来不算复杂。但有几个点要注意，不然会浪费很多时间。

⚠️ 注意： KITE 依赖 Chrome 或 Chromium 浏览器，并且需要安装对应的 WebDriver。版本一定要匹配，否则浏览器启动会报错。

基本的安装步骤：

安装 Node.js（推荐 v14 以上）
全局安装 KITE CLI：npm install -g kite-cli
下载对应版本的 ChromeDriver，放到 PATH 里
准备一个 KITE 配置文件（kite.config.json）

配置文件长这样：

{
  "browsers": [
    {
      "type": "chrome",
      "count": 50,
      "headless": true,
      "args": ["--use-fake-device-for-media-stream"]
    }
  ],
  "test": {
    "script": "./test-scripts/basic-call.js",
    "duration": 120,
    "concurrent": true
  },
  "metrics": {
    "enabled": true,
    "interval": 1000,
    "output": "./reports/"
  }
}

这里有个小技巧：--use-fake-device-for-media-stream 这个参数很重要。它让 Chrome 使用虚拟的摄像头和麦克风，而不是真的去调用你的硬件。不然你开 50 个浏览器，每个都要抢摄像头，那画面太美我不敢看。

编写压力测试脚本

KITE 的测试脚本本质上就是 JavaScript，通过 KITE 提供的 API 来控制浏览器行为。我写了一个最简单的示例，模拟两个用户建立通话：

// test-scripts/basic-call.js
module.exports = async (kite) => {
  // 获取两个浏览器实例
  const browser1 = kite.getBrowser('chrome', 0);
  const browser2 = kite.getBrowser('chrome', 1);

  // 打开测试页面
  await browser1.navigateTo('https://your-webrtc-app.com');
  await browser2.navigateTo('https://your-webrtc-app.com');

  // 模拟用户点击「加入房间」
  await browser1.click('#join-btn');
  await browser2.click('#join-btn');

  // 等待连接建立
  await kite.waitFor(3000);

  // 检查连接状态
  const stats1 = await browser1.getStats();
  const stats2 = await browser2.getStats();

  // 记录指标
  kite.recordMetric('browser1_rtt', stats1.rtt);
  kite.recordMetric('browser2_rtt', stats2.rtt);
  kite.recordMetric('browser1_packetsLost', stats1.packetsLost);
  kite.recordMetric('browser2_packetsLost', stats2.packetsLost);
};

你想想看，如果只有两个用户，那叫功能测试。压力测试的关键在于「规模」。KITE 允许你指定浏览器数量，比如 50 个、100 个，甚至更多。它会自动并行启动这些浏览器，同时执行脚本。

💡 我的经验： 不要一上来就开 500 个浏览器。先开 10 个跑一轮，看看服务器响应时间。然后逐步增加：20、50、100、200。这样你能清晰地看到服务器在哪个临界点开始「喘气」。

分析服务器承载能力

跑完测试后，KITE 会生成一份报告。但报告是死的，你得会看。我个人习惯关注这几个核心指标：

指标	正常范围	危险信号
CPU 使用率	< 70%	> 90% 持续 30 秒以上
内存占用	< 80%	接近 100% 或触发 OOM
RTT (往返时延)	< 100ms	> 300ms 且持续上升
丢包率	< 1%	> 5% 用户会明显感知卡顿
并发连接数	根据服务器规格而定	连接建立失败率 > 5%

我记得有一次帮客户做压力测试，他们的 SFU 服务器在 50 路并发时表现完美，CPU 才 40%。但加到 80 路时，CPU 直接飙到 95%，丢包率也到了 8%。后来一查，是编码器线程数没调优，默认只用了 4 个线程。改成 8 个后，80 路稳稳的。

所以你看，压力测试不只是「测能不能扛住」，更是帮你找到瓶颈在哪。

避坑指南

我曾经踩过的几个坑：

浏览器资源泄漏： 长时间运行测试，Chrome 进程会越吃越多内存。建议每轮测试后强制杀掉所有 Chrome 进程，再启动下一轮。
网络带宽瓶颈： 如果你在单台机器上跑 100 个浏览器，每个浏览器都在发视频流，你的网卡可能先扛不住。建议用多台机器分布式部署 KITE。
测试数据失真： 虚拟设备生成的音视频流是固定的，没有真实场景中的运动、光照变化。有条件的话，可以混入一些真实摄像头采集的流。

嗯，说到分布式部署，KITE 本身支持多节点模式。你可以用一台机器当控制节点，其他机器当执行节点。控制节点负责分发脚本和收集结果，执行节点只负责跑浏览器。这样就能模拟出几百甚至上千路的并发压力。

最后说一句，压力测试不是一次性的事。每次服务器配置变更、代码升级、甚至机房迁移，都应该重新跑一轮。我见过太多「上线前测得好好的，上线后崩了」的案例，多半是环境变了但没重新测。

好了，关于 KITE 框架做压力测试，核心思路就是这些。工具是死的，思路是活的。你只要掌握了「逐步加压、监控指标、定位瓶颈」这个循环，换什么框架都一样。

📚 课程目录

24、压力测试：使用 KITE 框架进行大规模 WebRTC 压力测试，分析服务器承载能力

KITE 框架的核心架构

搭建 KITE 测试环境

编写压力测试脚本

分析服务器承载能力

避坑指南