Rust vs Go: WebRTC Data Channel 性能基准测试
· 阅读需 5 分钟
简介
在实时通信的世界中，性能至关重要。WebRTC 已成为点对点音频、视频和数据传输的标准。虽然浏览器实现众所周知，但服务器端和原生实现对于构建可扩展的基础设施、网关和高性能客户端至关重要。
本文展示了一项性能基准测试，比较了三种著名的 WebRTC 实现，代码可在 restsend/rustrtc 获取：
- RustRTC: 一个纯 Rust 实现的 WebRTC（被测项目）。
- webrtc-rs: 最流行的 Rust 实现（Pion 的移植版）。
- Pion: 业界标准的 Go 语言 WebRTC 实现。
方法论
基准测试侧重于 Data Channel（数据通道）的性能，特别是吞吐量和连接建立延迟。
- 环境: macOS, Apple Silicon (M-series), 10 个并发连接。
- 场景:
- 在本地建立 10 个 PeerConnection（回环）。
- 在每个连接上打开一个 Data Channel。
- 尽可能快地发送 1KB 数据包，持续 10 秒。
- 测量传输的总字节数、发送的消息数、连接延迟、CPU 使用率和内存占用。
- 模式: Release 构建 (
cargo run --release)。
基准测试架构
基准测试套件旨在隔离并测量每个库中 Data Channel 实现的原始性能。架构包含以下组件：
-
驱动与隔离: 主基准测试运行器是用 Rust 编写的。它在单独的进程中执行每个实现（RustRTC, webrtc-rs, 和 Pion）。这确保了一个实现的资源使用（CPU 和内存）不会干扰另一个，并允许进行精确的基于
ps的监控。 -
并发模型:
- 测试生成 10 对并发 PeerConnection。
- 每一对都在其自己的异步任务（Go 中的 Goroutine，Rust 中的 Tokio 任务）中运行，以模拟多客户端服务器环境。
-
流量模式（负载测试）:
- 设置: 每一对执行本地回环连接（DTLS/SRTP 握手）并建立 Data Channel。
- 爆发阶段: 连接后，发送方进入紧密循环，尽可能快地发送 1KB 数据包，持续 10 秒。
- 流控: 测试依赖于底层的 SCTP 流控。发送方尝试使通道饱和。
-
指标收集:
- 吞吐量: 通过将所有 10 个连接接收的总字节数除以持续时间计算得出。
- 资源监控: 一个专用的后台线程通过定期轮询操作系统（通过
ps命令）来监控进程的 RSS 内存和 CPU 使用率，确保监控本身的开销最小。
结果
Comparison (Baseline: webrtc)
Metric | webrtc | rustrtc | pion
--------------------------------------------------------------------------------
Duration (s) | 10.02 | 10.02 | 11.02
Setup Latency (ms) | 1.14 | 0.69 | 1.80
Throughput (MB/s) | 135.45 | 213.38 | 177.92
Msg Rate (msg/s) | 138696.71 | 218497.60 | 182190.56
CPU Usage (%) | 820.38 | 829.33 | 596.12
Memory (MB) | 28.00 | 10.00 | 41.00
--------------------------------------------------------------------------------
1. 吞吐量 (MB/s)
吞吐量是所有连接每秒传输的数据总量。
Throughput (MB/s) (Higher is better)
webrtc | █████████████████████████ 135.45
rustrtc | ████████████████████████████████████████ 213.38
pion | █████████████████████████████████ 177.92
分析:
- RustRTC 展示了最高的吞吐量，达到 213.38 MB/s。
- Pion 紧随其后，达到 177.92 MB/s。
- webrtc-rs 达到 135.45 MB/s。
RustRTC 处于领先地位，展示了其实现的高效性。Pion 表现出人意料地好，在这个特定的吞吐量测试中超过了 webrtc-rs，表明其近期版本或特定测试配置下有显著优化。
2. 消息速率 (msg/s)
与吞吐量类似，这测量每秒处理的 1KB 消息数量。
Message Rate (msg/s) (Higher is better)
webrtc | █████████████████████████ 138696.71
rustrtc | ████████████████████████████████████████ 218497.60
pion | █████████████████████████████████ 182190.56
分析:
- RustRTC 每秒处理超过 21.8 万条消息。
- Pion 每秒处理约 18.2 万条消息。
- webrtc-rs 每秒处理约 13.8 万条消息。
3. 连接延迟 (ms)
建立 PeerConnection 所需的时间（DTLS 握手 + ICE 连接）。
Latency (ms) (Lower is better)
webrtc | █████████████████████ 1.14
rustrtc | █████████████ 0.69
pion | ███████████████████████████████████ 1.80
分析:
- RustRTC 建立连接最快 (0.69 ms)。
- 所有三个实现在回环上都极快，连接时间均在 2ms 以内。
4. 资源使用
CPU Usage (%) (Lower is better)
webrtc | ███████████████████████████████████████ 820.38
rustrtc | ████████████████████████████████████████ 829.33
pion | ████████████████████████████ 596.12
两个 Rust 实现都有效地利用了可用的 CPU 资源来最大化吞吐量。Pion 使用较少的 CPU，但实现的吞吐量明显较低，表明它可能受到其他因素（锁、GC 或运行时调度）的限制。
Memory (MB) (Lower is better)
webrtc | ███████████████████████████ 28.00
rustrtc | █████████ 10.00
pion | ████████████████████████████████████████ 41.00
分析:
- RustRTC 最节省内存，仅使用 10 MB。
- webrtc-rs 使用 28 MB。
- Pion 使用 41 MB，这非常合理且与 Rust 实现相当，显示了有效的内存管理。
结论
在这个 Data Channel 基准测试中：
- RustRTC 占据榜首，提供了最高的吞吐量、最低的延迟和最低的内存占用。
- Pion 表现出令人印象深刻的性能，在吞吐量方面位居第二，并保持了较低的内存使用率，证明它是高性能场景下非常有能力的实现。
- webrtc-rs 仍然是一个稳健的执行者，资源使用稳定，尽管在此特定基准测试中的原始吞吐量方面稍显落后。
对于需要最大效率、低延迟和高吞吐量的用例（如云游戏、实时文件传输或高频服务器端处理），RustRTC 是一个令人信服的选择。