Because the clients are real Chromium instances, the numbers come from the RTC peer connections themselves — packet loss, round trip time, jitter buffer delay, quality limitation — rather than from a synthetic traffic generator, and the throttle rules can degrade one participant's uplink at a set moment to see what the service does about it. Two things shape where you run it: throttling needs Linux, and the machine hosting the sessions has to have the CPU and bandwidth for every client you start, or you end up measuring your own laptop.
The MCP mode of WebRtcPerf, a load-testing tool that spawns Puppeteer-driven Chromium sessions against a WebRTC service and collects the statistics its peer connections report. Four tools start, stop, list and reset sessions; everything else is the config object you hand to start_session.
- start_session takes the session config — url, tabsPerSession, throttleConfig and the rest of the tool's options — and returns the id it created
- get_sessions lists the running sessions with their stats, so a test in progress can be read without waiting for it to end
- stop_session ends one by id, and reset_stats clears the collected statistics so a new measurement window starts clean
- Statistics are aggregated across sessions with sum, mean, standard deviation, 5th and 95th percentile, min and max: bitrate, packet loss, round trip time, jitter, jitter buffer delay, sent resolution and fps, FIR and PLI counts, and quality limitation from CPU or bandwidth
- System CPU, GPU and memory alongside per-page CPU and RSS, so client-side exhaustion is distinguishable from a server-side limit
- Network throttling per session through throttleConfig: rate, delay, delay jitter and distribution, packet loss and loss burst, reordering and queue size, applied to uplink or downlink and to TCP or UDP separately
- Throttle rules carry an at value, so bandwidth can be dropped mid-test and restored later without restarting anything
- Injected page scripts, which is what lets a session get past a join screen into an actual room
No account for the tool itself — you need whatever the service under test needs. Node.js with Chromium available, FFmpeg installed on the same machine, and it runs as npx -y @vpalmisano/webrtcperf@latest --mcp; a prebuilt Docker image and a global npm install are the other two routes. Linux is the recommended platform, and the network throttling specifically depends on the Linux Traffic Controller framework. Concurrent sessions consume CPU, memory and bandwidth in proportion to the number of clients you start. AGPL.
One command — npx -y @vpalmisano/webrtcperf@latest --mcp