BigBlueButton Capacity Planning & Hardware Sizing: CPU Core Scaling, RAM Allocation & TURN Bandwidth Math

Deploying BigBlueButton into a enterprise production environment requires moving beyond generic "recommended specs." Unlike web application servers that scale predictably based on HTTP requests per second, real-time WebRTC conferencing platforms consume system resources non-linearly.

A server running 10 virtual rooms with 10 participants each behaves radically differently than a server running a single webinar with 100 participants—even though both scenarios total 100 concurrent users.

To prevent audio dropouts, WebRTC media freeze, and CPU throttling during peak lecture hours, infrastructure architects must master the physical mathematical models governing CPU core pinouts, FreeSWITCH audio thread allocation, TURN socket exhaustion, and network transit math.

In this guide, Bymond provides the exact capacity planning equations and hardware provisioning matrix used by our DevOps team to operate high-concurrency BigBlueButton environments.

The Non-Linear Math of Real-Time WebRTC Media Streams

The resource consumption of BigBlueButton is dictated by the interaction of three distinct media channels:

WEBRTC RESOURCE CONSUMPTION MATRIX:
+-------------------------------------------------------------------+
|  1. FreeSWITCH Audio Bridge (SIP / Opus Codec Transcoding)        |
|  2. mediasoup / Kurento SFU (WebRTC Video Forwarding)             |
|  3. bbb-html5 Frontend Workerset (Meteor / Node.js Process Pool)  |
+-------------------------------------------------------------------+

1. WebRTC Video Stream Sizing Formula

In a session with $N$ total participants where $V$ participants publish webcams at bitrate $B_v$ (e.g., 600 kbps for 720p video), the total outbound video bandwidth generated by the server is calculated as:

• Small Classrooms (10 rooms, 10 users each, 2 webcams per room):

• Large Webinar (1 room, 100 users, 5 webcams published):

Even though user counts are identical, the single large webinar generates nearly 3x the video bandwidth and CPU load on the WebRTC Selective Forwarding Unit (SFU).

Hardware Provisioning Equations

To calculate hardware requirements for a target capacity of $U$ concurrent users across $M$ active classrooms, use Bymond's sizing formulas:

HARDWARE PROVISIONING EQUATIONS:

1. CPU Physical Cores Required:
   Cores = 4 + ceil( (Total Active Webcams * Total Viewers * 0.0015) + (Total Audio Users * 0.008) )

2. System RAM Allocation (GB):
   RAM_GB = 16 + (0.015 * Total Active Users) + (2.5 * Active NodeJS HTML5 Workers)

3. Network Transit Pipeline (Mbps):
   Bandwidth_Mbps = ( (V_total * U_avg * 0.6) + (U_total * 0.048) ) * 1.25 [Safety Margin]

Recommended Bare-Metal Configuration Matrix

Virtualized cloud VMs (e.g., standard EC2 instances) often suffer from noisy-neighbor CPU credit throttling and unpredictable network jitter. For production BigBlueButton workloads exceeding 300 concurrent users, dedicated bare-metal hardware is strongly recommended.

FreeSWITCH Audio Optimization & Core Pinning

FreeSWITCH handles all Opus audio encoding and SIP bridge connections in BigBlueButton. Under high concurrency, Linux scheduler process migration between CPU sockets introduces audio packet jitter.

Core Pinning via Systemd Overrides

To isolate FreeSWITCH on specific physical CPU cores (e.g., cores 4 through 15) and prevent background OS tasks from interrupting audio processing, configure systemd CPU affinity:

# /etc/systemd/system/freeswitch.service.d/override.conf
[Service]
CPUAffinity=4 5 6 7 8 9 10 11 12 13 14 15
Nice=-15
LimitRTPRIO=99

TURN Relay Socket & Network Port Tuning

When students join live classes from behind restrictive enterprise firewalls, corporate proxies, or mobile networks, direct UDP WebRTC connections fail. Up to 25% of all live audio/video traffic relies on TURN relays (UDP/TCP fallback on port 443).

TURN RELAY ARCHITECTURE:
[ Restrictive Corporate Firewall ] ---> [ TURN Relay (Port 443 TCP/TLS) ] ---> [ BBB Media SFU ]

Essential Linux Kernel Tuning (`/etc/sysctl.conf`)

To prevent TURN server socket exhaustion (epoll file descriptor limits) during high-concurrency spikes, apply the following kernel parameters:

# Increase maximum open file descriptors for WebRTC sockets
fs.file-max = 2097152

# Network socket buffer optimization for 10G NICs
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 100000
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.ip_local_port_range = 1024 65535

Summary & Next Steps

Accurate capacity planning is the foundation of high-availability BigBlueButton infrastructure. Provisioning dedicated bare-metal hardware, isolating FreeSWITCH audio threads, and tuning TURN sockets guarantees sub-second WebRTC latency during campus peak hours.

• Explore how Bymond manages high-concurrency WebRTC clusters on our Virtual Classroom Solutions page.
• Read our multi-server cluster guide: Scalelite Multi-Server Architecture.
• Prefer guaranteed turnkey hosting with dedicated bare-metal infrastructure? Visit BigBlueButton Managed Hosting.
• Request a custom infrastructure capacity audit: Contact Bymond Infrastructure Engineers.