Prerequisites

My system is a Debian buster virtual server with two CPUs and four gigabytes of RAM. To preempt a bit of the later measurements, the entire system did not exceed a usage of 1.2 GiB, so RAM-wise it is slightly overpowered.

Since Jitsi Meet is, among others, a web application, port 80 and 443 need to be free. In addition, you’ll have to be able to send and receive traffic on ports 4443/tcp and 10000/udp, via both IPv4 and IPv6 (if you have that; neither IPv4 nor IPv6 is a strict requirement, but you’ll need it if you have IPv4/IPv6-only users). If you are behind NAT, you can configure Jitsi Meet to understand that.

If you already have a webserver installed, you’ll have to configure the web part yourself. There is a Manual Install document which goes into some of the aspects you need to handle in such a case.

Installing Jitsi Meet

To install Jitsi Meet on Debian, you first have to enable the apt repository by the Jitsi developers. If you, like me, do not like enabling third-party repositories on productive servers, I suggest you put your Jitsi instance in an LXC-based container. Or maybe inside Docker. Though if you go with Docker, you may be interested in docker-jitsi-meet instead.

You need to follow the linked Quick Install document up to the point where apt install jitsi-meet is called. During the installation you’ll be asked for two things: A domain name under which you want to serve your instance (which you cannot easily change later) and whether you want to use existing certificates.

We’ll refer to the domain name you gave as $HOSTNAME in the following.

They then suggest to install Let’s Encrypt certificate using the script they provide. I found that this script downloads certbot-auto from the EFF website without further signature checking and executes it as root. This isn’t ideal.

You can instead use certbot, but you have to patch the nginx configuration created by the package slightly by adding the following lines to /etc/nginx/sites-enabled/$HOSTNAME.conf, where $HOSTNAME is the domain name you gave Jitsi during the installation with apt.

location ~ ^/\.well-known/.+$ {
    try_files $uri @root_path;
}

Then you can install certbot (apt install certbot) and request a certificate:

# certbot certonly -d $HOSTNAME --webroot --webroot-path /usr/share/jitsi-meet

Again, replace $HOSTNAME with the domain name of your Jitsi Meet installation. Note that certbot automatically puts itself into crontab so renewal will happen automatically. It will, however, not auto-reload nginx. To achieve that, you can add your own crontab entry which calls systemctl reload nginx, for example once per day or week.

Jitsi Meet configured nginx to load the certificates from /etc/jitsi/meet/, so we have to create symlinks there so that nginx finds the correct certificates:

# rm /etc/jitsi/meet/$HOSTNAME.{crt,key}
# ln -s /etc/letsencrypt/live/$HOSTNAME/fullchain.pem /etc/jitsi/meet/$HOSTNAME.crt
# ln -s /etc/letsencrypt/live/$HOSTNAME/privkey.pem /etc/jitsi/meet/$HOSTNAME.key
# systemctl reload nginx

If you want to use IPv6, you also need to fix the nginx configuration which will currently only offer the Jitsi service on IPv4. To do that, you need to duplicate the listen directives in /etc/nginx/sites-enabled/$HOSTNAME.conf to also listen on IPv6. So instead of listen 80;, you need the following:

listen 80;
listen [::]:80;

And analogously for listen 443 ssl;.

At this point, you should already be able to reach the Jitsi Meet instance from your browser.

Authentication

As you noticed, your Jitsi Meet instance is currently available to anyone who knows the domain name. This is not ideal. You can secure the instance by enforcing authentication. This is documented in the Secure Domains section of the Jicofo service.

Experiment Setup

• Debian Buster VM at Hetzner (CX21, but with only 20 GB disk because I opted out of the disk resize when scaling up from the CX11 I had before)
• Jitsi Meet installed in an LXC container (managed via libvirt)
• IPv6 directly routed to the LXC container, IPv4 via DNAT (stateful, more on that later)
• Initially five people, later six people peak, with seven clients (more on that later)
• Monitoring with Prometheus:
  • CPU time metrics of the VM via node-exporter
  • Memory use metrics of the VM
  • Network traffic on eth0 of the VM
  • Network traffic on the various Jitsi ports (80, 443, 4443/tcp and 10000/udp) using nftables counters and the nftables_exporter
• The VM also functions as a shell server, so there were two poezio instances running which caused a baseline of CPU and memory use.

Timeline

First off, you can look at the data yourself. I took an interactive snapshot on my Grafana instance for you to look at.

For everyone else, there’s also a screenshot:

In the second graph on the left side, I marked a few points of interest. I will now go through them one by one.

1. A around 16:45, we set up the conference. My wife and I joined first, then shortly after 17:00, the first player came along. We chatted a bit and optimised the sound setup. Then the second player tried to join, but was unable to get audio or video to work.

   I looked into it and found error messages indicating that no WebRTC session came to be between the Videobridge and the player’s computer. After a while of messing around, I noted that I forgot to configure Videobridge to make it aware of the IPv4 NAT, and this was the first person to not have IPv6. After applying the NAT configuration from the documentation ...

2. ... I restarted the videobridge which kicked everyone out of the conference. The two players from before were able to join (this time with audio!) and a third player came along shortly thereafter. This worked for quite a while stably.

3. We had issues with one of the two Firefox users getting frozen video. This happened immediately as soon as a second Firefox user was present, which was odd. I recommended one of them to switch to Chromium. That fixed the issue for them, but the other Firefox user still had frozen video. The switch to Chromium is what caused the drop in traffic.

   There are two reasons for this: First, the video quality actually dropped a bit when the player switched. Second, there is a problem with Jitsi Meet and Firefox. Normally, Jitsi Meet will continuously send three video streams to the Videobridge: A low definition one, a standard definition one and a high definition one. Then the other clients indicate which version of the streams they want and the videobridge will only send the requested one to the other clients.

   Most of the time, you don’t have a participant in full screen, so getting a HD stream makes no sense; your Jitsi Meet in the browser will request SD (if you use the tiled view) or LD (if the participants are folded to the side) video streams.

   Since Firefox isn’t able to send multiple stream versions, Jitsi Meet only sends the HD one. That means that everyone will always get the HD stream of all firefox participants, even if they’re only a 64x64 square on the side. We’ll see more data to support this in a bit.

4. The last player joined. They also joined with Firefox, and immediately we see the traffic jump up by a significant bit. We still had the issue that one member was getting frozen video streams.

5. At this time, we tried to fix the frozen video streams again (they didn’t go away by switching the other user to chromium).

   I set up a victim firefox on my laptop to catch the "disease of the frozen streams" while the new player switched to chroimum. That worked. So I turned of video and audio for my firefox client and let it sit there for the rest of the session.

   The drop in traffic was again caused by a player switching to Chrome, though this time without loss in video quality.

After the initial hiccups, Jitsi worked mostly smoothly. One player was having a bad connection and dropped out for a few seconds a few times, but other than that it was pretty good and reliable.

Resource Consumption summary

In the last section of the graph, the setup was continuously as follows:

• Seven clients
• Five clients which received video
• Five clients which sent audio
• Two firefox clients, only one of which sent video
• Five chrome/chromium clients

The CPU load in the graphs is normalised to full load on all cores. That means if you see a CPU load of 100% in the graph, it implies that all cores were fully utilised. Note that the blue line in the CPU graph is in fact the load5 metric of the system and uses the right axis, while the other data uses the left axis and is CPU time spent per second.

The Jitsi Meet conference thus used approximately 80% of a CPU core continuously. Due to the high amount of threads, the load5 was wiggling around 2.0. Memory use started out at ~950 MiB without Jitsi Meet running and then gradually rose to approximately 1.15 GiB. This means approximately 200 MiB of memory used by the server-side components of Jitsi Meet for seven clients.

The memory has not been fully released afterwards though, which makes me think that some of this is overhead caused by memory fragmentation.

The traffic totalled at about 75 GiB (50 GiB tx, 25 GiB rx) on the server side. With only one Firefox client sending video, we had about 2 MiB/s tx and 1 MiB/s rx on the server, which is quite low all over all. I suspect that eliminating the last Firefox client will improve the situation even more.