OpenVidu 3.8: reconciling published capacity with our 100-student classroom tests

Hello folks,

We’re qualifying our platform’s live classrooms on OpenVidu 3.8 and need your help choosing the engine and sizing our media servers.

Your documentation gives two capacity figures we would like to understand:

  • One publisher and 1,000 viewers in a single room on a four-CPU server. Scalability documentation

  • Nearly twice the participant/track capacity with mediasoup versus Pion in your multiple-room benchmark, using eight participants per room. Performance benchmark

Our classroom workload is different:

  • One room with 100 students and two teachers.

  • Two teachers and one student each publish camera, screen, microphone and screen audio; the remaining students watch; equivalent to 100*6 = 600 streams.

  • Three 640×360 cameras and three 1920×1080 screens, with actual sources running at approximately 15fps.

  • Recording enabled on the media node.

  • DigitalOcean Regular CPU-Optimized server: four dedicated vCPUs, 8 GiB RAM.

We ran the same scenario twice with each engine. Each run gradually admitted 100 students, then attempted a 15-minute hold at full attendance. Application/browser versions, publishing settings and quality thresholds were unchanged. Browser load was distributed across separate workers. Server plans and CPU models matched, but the engines used fresh instances rather than the identical physical host.

Measurement Pion Mediasoup
First run Passed full hold Passed full hold
Repeat run Passed full hold Failed after 10m23s at full attendance
Average total media-server CPU 67.4% / 68.9% 55.4% / 55.5%
Average busiest forwarding thread, as % of one core 29.0% / 29.7% 78.9% / 78.5%
Maximum sampled busiest forwarding thread 51.6% / 53.4% Approximately 100% in both runs

Mediasoup’s repeat-run averages cover only the period before failure.

In that failure, one student experienced 1.29–2.36% audio packet loss across six audio streams, exceeding our 1% threshold, and approximately 1.3-second video stalls. Other viewers recorded shorter stalls. We found no matching overall CPU saturation or UDP buffer errors. Both recordings completed and decoded successfully.

We want to understand:

  1. What setup produced the 1,000-viewer result? Which engine, CPU model, video resolution/bitrate and test duration were used? Was recording enabled, and were packet loss and freezes measured, or mainly successful connections? We want to understand whether our results are unexpectedly poor or simply reflect a different workload.

  2. Should we expect mediasoup’s near-2× advantage in our single classroom? We understand that the published comparison uses multiple smaller rooms. For one room with three publishers sharing both camera and screen, would you recommend mediasoup or Pion?

  3. Can one mediasoup room reach a forwarding-thread limit while other cores remain available? Our thread measurements differ substantially between engines. Would adding more vCPUs help this room, or would faster individual cores be necessary? What server configuration would you recommend for this workload with recording and sensible headroom?

  4. Does the interruption resemble a known 3.8 issue? Is there a patch or configuration we should check? If another reproduction is needed, please tell us exactly what additional evidence to collect. We have timestamped browser WebRTC statistics, publisher feedback, provider logs and per-thread CPU measurements.

We are not assuming the published figures are directly comparable, or that mediasoup caused the failure. We want to understand the difference and choose a configuration we can reliably release.

Basically, we want to achieve this claim - “One publisher and 1,000 viewers in a single room on a four-CPU server.”, what are we missing?

Thanks,
Ruchir

Citing a response via email from @pabloFuente :

Hello,

Answering your questions:

1. The 1000-viewer result is an estimation provided by our load tests performed some time ago (OpenVidu 3.4.0). It assumed 640x480p video resolution, in an 8-to-8 video conferencing topology (8 client-to-server video tracks, 56 server-to-client video tracks, per room). All run in AWS EC2 instance (c5.xlarge, with 4 vCPUs). No recording, no other tasks performed on the Media Node. Those numbers are actually taken from this cluster example of the Pricing page. We simply measured maximum capacity (whenever the node reached 100% CPU usage, and no more rooms be successfully established).

2. / 3. mediasoup offers a 2x performance boost compared to pion, but it is possible that for use cases with three 640p webcam tracks, three 1080p screen tracks and 100 suscribers, the single-core thread used by mediasoup at the moment may be a hard limit. Up until version 3.8.0, all the tracks of a Room must fit in the same CPU core when using mediasoup. For large-scale Rooms, that can be a problem. Of course, that also means that adding more cores won’t help, but using faster, more powerful individual cores will increase the capacity per-room. We are currently working on adding multi-thread support in mediasoup workers to allow taking up advantage of all cores in the node in large scale Rooms, and will probably be the main feature of release 3.10.0 (we are planning to release 3.9.0 in the following weeks). For now, if you are seeing an upper limit when using mediasoup, we recommend switching to pion in the meantime.

Also, recording is a very CPU demanding process. For COMPOSED recording (grid layout being transcoded in real time), we recommend at least 2 free, dedicated CPU cores for each active recording process.

4. The summary of the previous points is that you may be hitting an upper capacity limit when using mediaosup for 6 publisher + 600 suscriber videos being routed through the same CPU core. A current limitation of mediasoup RTC engine, which will be addressed in a future release.

I hope my answers are helpful.

Best regards,