Moving a Rust WebRTC SFU to thread-per-core: 70ms → 10ms P99.99 latency
DRANK
We recently migrated our open-source Rust WebRTC SFU server from Tokio's default multi-threaded work-stealing model to a thread-per-core (TPC) architecture, reducing P99.99 end-to-end latency from a spiky 70ms to a stable 10ms, while increasing system capacity by 25%.P99.99 end-to-end latency before and after the thread-per-core migration.WebRTC SFU OverviewThink of a WebRTC Selective Forwarding Unit (SFU) as a high-performance, low-latency router for real-time media. Acting like a pub/sub broker, it takes in video and data streams from a publisher and forwards them to subscribers using payload-specific transport optimizations. It doesn't do heavy server-side transcoding. It's the core technology that makes massive, Zoom-like video apps work.An SFU forwarding streams between three participants in a room.Early DesignPulseBeam is a standalone WebRTC SFU server rather than a library. The first version of our WebRTC SFU was built in Rust on Tokio's multi-threaded scheduler. We used the mo…
WebRTCみたいに小さい単位の処理をするサーバだとワークスティーリングのオーバーヘッドに耐えられないので並行性を落とすが1スレッドで返信までやってしまうのがよい
Moving a Rust WebRTC SFU to thread-per-core: 70ms → 10ms P99.99 latency | PulseBeam Blog
pulsebeam.dev/blog/moving-to…