29、WebRTC性能测试方法论：自动化压测工具、模拟弱网环境、性能基准与回归测试
性能测试这件事，说实话，很多团队都是「上线前跑一跑，出问题了再补」。但WebRTC不一样——它太脆弱了。网络抖动、CPU过载、内存泄漏，任何一个环节出问题，用户那边的表现就是卡顿、花屏、断连。我见过太多项目，功能都跑通了，一上生产环境就崩，原因就是没做系统的性能测试。
今天这一章，我就把压测工具选型、弱网模拟、基准线建立、回归流程这四块内容，一次性讲透。你照着搭，至少能避免80%的线上性能事故。
一、自动化压测工具：选对工具，事半功倍
压测WebRTC，和压测HTTP API完全是两码事。HTTP你只管发请求、收响应就行。WebRTC要模拟真实的媒体流、信令交互、ICE连接过程。工具选不对，测出来的数据就是废的。
1. 我常用的三款工具
| 工具 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| KITE | 端到端压测、多浏览器兼容 | 官方维护、支持Selenium集成 | 配置复杂、学习曲线陡 |
| Janus Gateway + 自定义客户端 | 服务端压测、模拟大量并发 | 可控性极高、可定制信令 | 需要自己写客户端代码 |
| Google Chrome DevTools Protocol | 单机性能分析、内存/CPU监控 | 无需额外部署、数据精确 | 不适合大规模并发 |
我个人习惯用KITE做回归测试，用Janus做容量压测。为什么呢？KITE能直接跑在真实浏览器上，测的是「用户真实体验」；Janus可以模拟几千路流，测的是「服务端极限」。
2. 一个简单的压测脚本示例（基于Janus）
// 伪代码：模拟100路并发推流
const NUM_STREAMS = 100;
const JANUS_URL = 'wss://your-janus-server:8188';
async function simulatePublisher(id) {
const session = await Janus.createSession({ url: JANUS_URL });
const plugin = await session.attachPlugin('janus.plugin.videoroom');
// 创建本地媒体流（模拟摄像头）
const stream = await navigator.mediaDevices.getUserMedia({
video: { width: 640, height: 480, frameRate: 30 },
audio: true
});
await plugin.joinRoom({ roomId: 1234, ptype: 'publisher' });
await plugin.publish({ stream });
console.log(`Publisher ${id} started`);
}
// 启动100路
for (let i = 0; i < NUM_STREAMS; i++) {
simulatePublisher(i);
}
嗯，这里要注意：跑这种脚本前，一定要先确认服务端的带宽和CPU上限。我曾经在测试环境直接跑了500路，结果Janus进程直接OOM，连SSH都连不上去……
二、模拟弱网环境：别让用户替你发现网络问题
WebRTC最怕什么？不是高延迟，而是抖动和丢包。你想想看，延迟高顶多是画面慢半拍，但丢包会导致花屏、卡顿、甚至断流。所以弱网模拟是性能测试的必修课。
1. 工具推荐
- Clumsy（Windows）：轻量级，可以模拟丢包、延迟、抖动、带宽限制。适合开发机自测。
- NetEm（Linux）：内核级网络模拟，精度高，适合自动化测试环境。
- Augmented Traffic Control（Facebook开源）：支持Wi-Fi和4G场景模拟，适合移动端测试。
2. 我常用的弱网参数模板
| 场景 | 延迟 | 丢包率 | 抖动 | 带宽限制 |
|---|---|---|---|---|
| 理想Wi-Fi | 10ms | 0% | ±5ms | 无限制 |
| 普通4G | 50ms | 1% | ±20ms | 2Mbps |
| 弱4G（地铁） | 150ms | 5% | ±50ms | 500Kbps |
| 极差网络 | 500ms | 15% | ±100ms | 200Kbps |
用NetEm设置弱网的命令很简单：
# 模拟4G弱网：延迟150ms，丢包5%，抖动±50ms
sudo tc qdisc add dev eth0 root netem delay 150ms 50ms loss 5%
我曾经在项目里遇到一个坑：弱网下视频能正常播放，但音频断断续续。排查了半天，发现是音频的FEC（前向纠错）没开。所以弱网测试一定要覆盖音视频双流，别只盯着视频看。
三、性能基准与回归测试：没有基线，优化就是瞎忙
你优化了一个参数，怎么知道是变好了还是变差了？没有基准线，你连「优化」的定义都说不清楚。我见过太多团队，今天改个码率，明天调个分辨率，最后性能反而下降了——因为没有回归测试。
1. 建立性能基准的四个核心指标
- 端到端延迟（E2E Latency）：从发送端采集到接收端渲染的时间。正常应 < 300ms。
- 丢包率（Packet Loss）：包括音频和视频。视频丢包率 < 2% 算合格。
- CPU使用率：编码器、解码器、渲染线程的CPU占比。超过80%就要警惕。
- 内存占用：尤其是长时间通话后的内存泄漏。我习惯跑24小时压测来验证。
2. 回归测试流程（我自己的实践）
- 每次代码合并前：自动触发一次基准测试，跑5分钟，记录所有指标。
- 与上一次基线对比：如果延迟增加超过10% 或 丢包率翻倍，自动阻断合并。
- 每周一次全量回归：覆盖所有弱网场景（4G、弱4G、极差网络）。
- 每月一次长稳测试：跑24小时，检查内存泄漏和CPU漂移。
核心原则：性能回归测试必须自动化，不能靠人工「跑一下看看」。我见过一个团队，每次发版前手动测一次，结果有一次漏测了内存泄漏，上线后服务每4小时重启一次……
四、知识体系总览
下面这张图，我把本章的核心逻辑画出来了。你可以把它贴在墙上，每次做性能测试时对照着看。
我的建议：别想着一步到位。先搭一个最简单的压测脚本，跑通一条流。然后逐步增加并发、加入弱网、建立基线。我见过太多人一开始就想搞「全自动化平台」，结果半年过去了，连一条流都没跑通。
避坑指南：我曾经在压测时发现CPU占用忽高忽低，排查了两天，结果是压测脚本里忘了释放MediaStream对象。所以写压测代码时，一定要关注资源释放。尤其是getUserMedia获取的流，用完记得调用track.stop()。
好了，这一章的内容就到这里。性能测试没有银弹，但只要你把工具选对、弱网覆盖全、基线建好、回归跑勤，WebRTC的性能问题基本都能提前发现。剩下的，就是不断迭代优化了。