why does my Jitsi deployment keep failing under load

A Jitsi deployment usually starts failing “under load” for one of a few predictable reasons: one bottleneck gets saturated and then cascades into the rest of the stack.

Common causes

1) JVB is overloaded first

The Jitsi Video Bridge (JVB) is usually the main scaling limit.

Typical symptoms:

• calls connect, then video freezes / drops
• poor quality after a certain number of participants
• high CPU on JVB
• packet loss or rising RTT
• “bridge selected” but media stalls

Common reasons:

• too few JVB instances
• one JVB handling too many endpoints
• not enough CPU or network bandwidth
• JVM settings too low/high for the machine
• NIC or kernel networking limits

2) Prosody / XMPP becomes a bottleneck

If signaling is weak, everything looks flaky even if media is fine.

Symptoms:

• slow room joins
• intermittent auth / presence failures
• users get disconnected or can’t enter rooms
• lots of XMPP reconnects

Common causes:

• Prosody underprovisioned
• too many connections on one node
• TLS/auth issues
• database or external auth latency

3) Jicofo can’t keep up with conference management

Jicofo handles conference orchestration, bridge selection, and room logic.

Symptoms:

• conferences don’t form reliably
• bridge allocation delays
• participants stuck “connecting”
• unstable behavior during spikes

Common causes:

• too few Jicofo instances
• CPU starvation
• slow XMPP or stats updates
• misconfigured bridge selection / region handling

4) NAT / firewall / UDP issues

Under load, network problems become more visible.

Symptoms:

• some users work, others don’t
• ICE failures
• relay usage spikes
• media works on some networks only

Common causes:

• blocked UDP ports
• bad NAT mapping timeouts
• TURN server overload or misconfig
• asymmetric routing / cloud security groups

5) Not enough TURN capacity

If clients can’t do direct UDP, TURN traffic can explode.

Symptoms:

• bandwidth spikes on TURN
• media delay and packet loss
• many clients fall back to relay

Common causes:

• TURN server undersized
• too few ports / too much egress traffic
• no autoscaling or rate limiting

6) Browser/client-side constraints

Sometimes the server is fine but clients fail as meeting size grows.

Examples:

• low-end devices can’t decode multiple video streams
• tab throttling / background tabs
• browser-specific issues with simulcast/SVC
• too many DOM updates in large rooms

7) Kubernetes / container resource limits

If you run Jitsi in containers, resource policy may be the culprit.

Symptoms:

• restarts, OOMKills, CPU throttling
• services healthy at low load, fail during spikes
• weird latency due to cgroup limits

Common causes:

• limits too tight
• no CPU pinning for JVB
• pod networking overhead
• node-level conntrack exhaustion

---

What to check first

1. Which service is failing?

   • JVB, Prosody, Jicofo, TURN, or frontend

2. Look at JVB metrics

   • CPU usage
   • conference count
   • packet loss
   • RTT
   • receiver/transformer queues
   • inbound/outbound bandwidth

3. Check logs during a spike

   • JVB: Too many video streams, ICE errors, queue warnings
   • Prosody: auth/presence disconnects
   • Jicofo: bridge selection failures, XMPP reconnects

4. Check resource saturation

   • CPU
   • memory / OOM kills
   • network bandwidth
   • file descriptors
   • conntrack table
   • UDP port exhaustion

5. Verify scaling architecture

   • more than one JVB
   • correct bridge advertisement / discovery
   • load balancing for signaling only, not media
   • TURN sizing

---

Very common mistake

People often scale Jicofo/Prosody/frontend but leave JVB as a single instance.
That makes the deployment look “bigger” while the actual media bottleneck remains unchanged.

---

If you want to diagnose it quickly

Send me any of these and I can help pinpoint the cause:

• your deployment type: Docker, Kubernetes, bare metal, Helm chart
• Jitsi component versions
• JVB CPU/memory/network during failure
• relevant log snippets
• number of participants and how many video streams per room
• whether failure means:
  • no one can join
  • join succeeds but media fails
  • quality degrades after N users
  • only some networks fail

If you want, I can also give you a step-by-step Jitsi load troubleshooting checklist or help interpret specific logs/metrics.