Webserver drastically slows down when a meeting is ongoing



I’ve set up my Jitsi server around 4 weeks ago (Ubuntu 16.04, installed from repository) and all is working great. But I have noticed one strange thing:

I’m monitoring my servers with Zabbix, and also the availability of the web services are monitored. With this, Zabbix also measures the time until the web page is delivered.

Jitsi usually responds between 100-200ms until the landing page is loaded.

But when a meeting is ongoing, the page load time increases to a constant 15 seconds!

In this example there was one meeting ongoing with two participants. The network traffic was around 8MBit/s in each direction (the server is connected with 1GBit/s), and the CPU was more or less boring at a peak of 4.7% out of 400 (Linux load 0.16/0.08/0.05) during the meeting.

So I don’t see any bottleneck in resources here … but why does the web server respond time go through the sky?


I suppose you are running a deployment where jvb is serving the page, jetty inside jvb. Can you try using nginx?


Hi @damencho

I’m running the standard install from the repository … the SSL port is handled by “Java”. So definitely not Nginx.

Is there a documentation how to change to Nginx? Any drawbacks with Nginx?


Well there is just one, if running nginx and jitsi-videobridge on the same machine. JVB will not be able to use port 443 for tcp media, which can be a problem in some restricted nats where udp is not allowed and just tcp ssl port 443. This is the reason choosing jetty instead of nginx in the default deployment. Other than that using nginx is more flexible.
The instructions are, if you want to use nginx install it before installing jitsi-meet.
Switching from jetty to nginx will be a manual process:


Hmmm, I did exactly what you wrote concerning the manual switching and I’m getting just a blank, dark grey page. Icon is the Jitsi icon, tab name is “Jitsi Meet” - but no content.

Anything we’re missing? Any more changes as I’ve secured my installation?

On the other hand … using port 443 also for media is very smart for clients behind a restrictive NAT. So maybe I’ll stick with JVB …


Well, you need to check the js console for errors to see what is wrong.