Jitsi Meet and the Number of Video Participants

Jitsi video conference
A Jitsi video conference with many participants – video channels pixelated for privacy 🙂

In the previous blog entry, I’ve been looking at a number of different commercial video conferencing solutions and if they offer native Linux support. There are a couple of fabulous products with good Linux support out there that easily support sessions with 15-20 simultaneous video participants. Unfortunately, from a privacy and confidentiality point of view, most of them don’t fare very well at all.

As confidentiality and privacy are very important to me, a potential solution for me and others is Jitsi, which is open source from client to server and can be installed on private infrastructure. The big question for me was however: How many video participants can the clients and the server handle in a single conference? A search on the web didn’t really result in a good answer. So I set out to find out for myself.

Jitsi can be installed with just a few commands on a virtual machine. So I started-off with a small 1 virtual CPU core instance with 2 GB of memory and 20 TB monthly traffic volume in a Hetzner data center in Germany for 3 euros a month to see how far I would get.

Installing Jitsi on the server is straight forward with their Docker container. All it takes is 4 commands on the shell! Yes, 4 commands! This gives you a running Jitsi instance on TCP port 8443 without encryption. A few additional commands give you a Letsencrypt certificate for a domain you own and which you have pointed to the IP address of the VM. This is important to get the Android and iOS apps running as they refuse to connect to the server that respond with a self signed certificate. More about installation in a separate post.

A Tiny Server Instance Setup

So, how far did I get with that small server? Much farther than I initially expected. Step by step I connected 8 clients, all broadcasting their video. At this point, the server’s CPU load reached 85% and I had 26 Mbit/s data traffic coming in and 17 Mbit/s going out. Memory usage was around 1 GB. Not bad, not bad at all! Also, things worked smoothly on the client side. The video of participants would sometimes drop for a few seconds and then come back but even after half an hour, there was no lag in the audio stream. On Linux, I used the Chromium browser as my Jitsi client, Firefox fails miserably. A known problem. On my Android phones I used the Jitsi app from the F-Droid store. I had one person join with an iPhone with the Jitsi app from the official Apple store. Worked like a charm as well.

Lecture Mode With One Presenter And Many Listeners

One of my conference needs is to hold a class to many participants and perform screen sharing, while the other participants don’t necessarily have to share their video. With 8 clients with audio only and 1 presenter client device on which the video was switched on, CPU load on the server was 50% and the network showed around 4 Mbit/s of data coming in and going out. In other words, in this mode of operation, many more participants could have joined the call.

A Server with 2 Cores

Server Load
Server load with 10 video streams in a conference

Next, I upgraded my VM to get 2 virtual cores and 4GB of memory which costs around 6 euros a month with 20 TB of data traffic included. In this setup both CPUs ran at around 70% with 10 clients and memory use was around 1.4 GBs at the beginning and 800 MB a little while later when everyone had joined and settled in. Data throughput was 52 Mbit/s incoming and 20 Mbit/s outgoing. In other words, I was far away from saturating the CPU with 10 simultaneous video streams in the conference. On the clients, things worked well, too, but I had the impression that the videos were not as smooth anymore as before.

Presenter Mode with 2 Cores

Server load
Server load with 10 clients, 1 screen sharer, 9 audio only.

When presenting to a larger audience with only one video stream running, the CPU cores ran at 44%, memory usage dropped to 740 MB and data traffic was 21 Mbit/s out vs. 3.8 Mbit/s. When switching to screen sharing, CPU loads dropped to 20%, memory use to 674 MB and the datarate on the server was negligible at 1 Mbit/s.


I ‘only’ had 10 devices to try this with but I’m pretty certain that unless the clients start getting a problem with a higher number of participants, video sharing will work with up to around 15 participants. With only one presenter showing a video, I’m pretty confident this setup will handle a much larger number of audio only clients that receive the video. For me the 15-20 ‘receivers’ is the critical mass, so this setup works for me.

6 thoughts on “Jitsi Meet and the Number of Video Participants”

  1. Martin, thanks for sharing you experiences! What are you using to get these nice ASCII bandwidth graphs?

  2. I am not sure about this, but someone explained to me today, that depending on the bowser used Jitsi has a p2p mode or not. Did you see anything like that?

    1. No, I didn’t look at that at all. I focused on the server component that distributes audio and video to all participants in a centralized fashion, as beyond 3 participants, p2p becomes a challenge in terms of data rates per device.

Comments are closed.