Rust vs Go: WebRTC Data Channel Performance Benchmark
Introduction
In the world of real-time communication, performance is paramount. WebRTC has become the standard for peer-to-peer audio, video, and data transfer. While the browser implementations are well-known, server-side and native implementations are crucial for building scalable infrastructure, gateways, and high-performance clients.
This article presents a performance benchmark comparing three prominent WebRTC implementations, with the code available at restsend/rustrtc:
- RustRTC: A pure Rust implementation of WebRTC (the project under test).
- webrtc-rs: The most popular Rust implementation (a port of Pion).
- Pion: The industry-standard Go implementation of WebRTC.
Methodology
The benchmark focuses on Data Channel performance, specifically throughput and connection establishment latency.
- Environment: macOS, Apple Silicon (M-series), 10 concurrent connections.
- Scenario:
- Establish 10 PeerConnections locally (loopback).
- Open a Data Channel on each connection.
- Send 1KB packets as fast as possible for 10 seconds.
- Measure total bytes transferred, messages sent, connection latency, CPU usage, and memory footprint.
- Mode: Release build (
cargo run --release).
Benchmark Architecture
The benchmark suite is designed to isolate and measure the raw performance of the Data Channel implementation in each library. The architecture consists of the following components:
-
Driver & Isolation: The main benchmark runner is written in Rust. It executes each implementation (RustRTC, webrtc-rs, and Pion) in a separate process. This ensures that the resource usage (CPU and Memory) of one implementation does not interfere with another and allows for accurate
ps-based monitoring. -
Concurrency Model:
- The test spawns 10 concurrent pairs of PeerConnections.
- Each pair runs in its own asynchronous task (Goroutine in Go, Tokio task in Rust) to simulate a multi-client server environment.
-
Traffic Pattern (Load Test):
- Setup: Each pair performs a local loopback connection (DTLS/SRTP handshake) and establishes a Data Channel.
- Blast Phase: Once connected, the sender enters a tight loop, sending 1KB packets as fast as possible for 10 seconds.
- Flow Control: The test relies on the underlying SCTP flow control. The sender attempts to saturate the channel.
-
Metrics Collection:
- Throughput: Calculated by summing the total bytes received across all 10 connections divided by the duration.
- Resource Monitoring: A dedicated background thread monitors the process's RSS memory and CPU usage by periodically polling the OS (via
pscommand), ensuring the overhead of monitoring itself is minimal.
Results
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. Throughput (MB/s)
Throughput is the total amount of data transferred per second across all connections.
Throughput (MB/s) (Higher is better)
webrtc | █████████████████████████ 135.45
rustrtc | ████████████████████████████████████████ 213.38
pion | █████████████████████████████████ 177.92
Analysis:
- RustRTC demonstrates the highest throughput at 213.38 MB/s.
- Pion follows with 177.92 MB/s.
- webrtc-rs achieves 135.45 MB/s.
RustRTC leads the pack, showing the efficiency of its implementation. Pion performs surprisingly well, outperforming webrtc-rs in this specific throughput test, indicating significant optimizations in its recent versions or the specific test configuration.
2. Message Rate (msg/s)
Similar to throughput, this measures the number of 1KB messages processed per second.
Message Rate (msg/s) (Higher is better)
webrtc | █████████████████████████ 138696.71
rustrtc | ████████████████████████████████████████ 218497.60
pion | █████████████████████████████████ 182190.56
Analysis:
- RustRTC processes over 218k messages per second.
- Pion handles approximately 182k messages per second.
- webrtc-rs processes around 138k messages per second.
3. Connection Latency (ms)
Time taken to establish the PeerConnection (DTLS handshake + ICE connectivity).
Latency (ms) (Lower is better)
webrtc | █████████████████████ 1.14
rustrtc | █████████████ 0.69
pion | ███████████████████████████████████ 1.80
Analysis:
- RustRTC establishes connections the fastest (0.69 ms).
- All three implementations are extremely fast, with sub-2ms connection times on loopback.
4. Resource Usage
CPU Usage (%) (Lower is better)
webrtc | ███████████████████████████████████████ 820.38
rustrtc | ████████████████████████████████████████ 829.33
pion | ████████████████████████████ 596.12
Both Rust implementations effectively utilize available CPU resources to maximize throughput. Pion uses less CPU but achieves significantly less throughput, indicating it may be bound by other factors (locking, GC, or runtime scheduling).
Memory (MB) (Lower is better)
webrtc | ███████████████████████████ 28.00
rustrtc | █████████ 10.00
pion | ████████████████████████████████████████ 41.00
Analysis:
- RustRTC is the most memory efficient, using only 10 MB.
- webrtc-rs uses 28 MB.
- Pion uses 41 MB, which is very reasonable and comparable to the Rust implementations, showing effective memory management.
Conclusion
In this Data Channel benchmark:
- RustRTC takes the top spot, offering the highest throughput, lowest latency, and lowest memory footprint.
- Pion shows impressive performance, securing the second place in throughput and maintaining low memory usage, proving it is a highly capable implementation for high-performance scenarios.
- webrtc-rs remains a solid performer with stable resource usage, though it trails behind in raw throughput in this specific benchmark.
For use cases requiring maximum efficiency, low latency, and high throughput (such as cloud gaming, real-time file transfer, or high-frequency server-side processing), RustRTC presents a compelling choice.