webrtc-bench is a WebRTC server that plays a video file from disk, and then re-distributes via WebRTC. It generates performance metrics including CPU usage, peer connection counts, and detailed latency measurements for connection setup phases.
This repo contains a CLI WebRTC Client that will connect and perform the load test. This is done via a REST API hosted on :8080/doSignaling. You can also watch the video/load test via the web UI at :8080/,
it connects via the same REST API as the CLI.
git clone https://github.com/pion/webrtc-bench.gitcd webrtc-bench/serverffmpeg -i $INPUT_FILE -g 30 -b:v 2M input.ivfgo run main.go
You can then access the Web UI at http://localhost:8080. This requires a browser that supports H264, this repo doesn't do any error handling around signaling failures.
You can also use the provided WebRTC CLI
cd webrtc-bench/clientgo run main.go localhost:8080
The benchmark generates three CSV files with performance data:
System-level metrics collected every 3 seconds:
timestamp, peerConnectionCount, cpuUsage, droppedLatencyMeasurements
2020-12-15T13:59:23-08:00, 1, 17.878028, 0
2020-12-15T13:59:26-08:00, 0, 35.101254, 0
2020-12-15T13:59:29-08:00, 1, 12.565718, 0
Detailed WebRTC connection setup timing from server perspective:
timestamp,type,latencyMs
2026-01-02T19:33:57.714Z,signaling_processing,13.391
2026-01-02T19:33:57.714Z,sdp_offer_processing,6.587
2026-01-02T19:33:57.714Z,sdp_answer_creation,0.365
2026-01-02T19:33:57.715Z,ice_gathering,0.255
2026-01-02T19:33:57.825Z,ice_connection,122.588
2026-01-02T19:33:57.979Z,dtls_handshake,153.612
Server Metrics:
signaling_processing: Total signaling time (offer → answer)sdp_offer_processing: SDP offer parsing timesdp_answer_creation: SDP answer generation timeice_gathering: ICE candidate gathering timeice_connection: Time from connection start to ICE connecteddtls_handshake: DTLS handshake completion time
Connection setup timing from client perspective:
timestamp,type,latencyMs
2026-01-02T11:33:57.706Z,ice_gathering,5001.234
2026-01-02T11:33:57.706Z,signaling_rtt,72.456
2026-01-02T11:33:57.811Z,ice_connection,5183.789
2026-01-02T11:33:57.916Z,dtls_handshake,104.123
2026-01-02T11:33:57.916Z,media_ready,5287.912
Client Metrics:
ice_gathering: ICE candidate gathering timesignaling_rtt: Round-trip time for signaling exchangeice_connection: Total time to ICE connecteddtls_handshake: DTLS handshake completion timemedia_ready: Total connection setup time
All latency measurements are recorded with sub-millisecond precision.
The following graph was generated from the results.csv that was generated by the server. The client was run from another EC2 instance in the same VPC.
The Y Axis is the CPU Usage, and the X Axis is the count of PeerConnections. This was run on a m4.2xlarge (Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz)
This is controlled by what video you use. You can go as high (or low) as you want.
SRTP_AEAD_AES_128_GCM
None, on purpose.
Pion by design allows the user to specify what they want. We are distributing a video feed that is already encoded, and has a very small keyframe-interval so these things don't help us.
When setting up the PeerConnection you have full control of the RTP/RTCP pipelines, so users can add TWCC/NACK/FEC in a way that works for them.
Join the Pion Discord!
Pion has an active community on the Discord.
Follow the Pion Bluesky or Pion Twitter for project updates and important WebRTC news.
We are always looking to support your projects. Please reach out if you have something to build!
If you need commercial support or don't want to use public methods you can contact us at [email protected]
MIT License - see LICENSE for full text