Introduction:

In our journey to host large virtual gatherings, we wanted to determine the capacity of a single shard in Jitsi Meet, assessing its performance under different scenarios. We focused on two distinct research approaches: one involved hosting a single conference to gauge its breaking point, while the other explored multiple conferences with a low participant count in each.

Hosting a Single Conference

Setting up the Environment

Our research commenced with the configuration of our AWS environment. We deployed two servers: one dedicated to Jitsi Meet, including Prosody and Jicofo, and the other allocated for the Jitsi Videobridge (JVB). For our initial testing phase, we opted for a c6a.large server, equipped with 2 vCPUs and 4GB of memory. Given Prosody's single-threaded nature, we selected a Compute Optimized server with just 2 cores to handle the task. To accommodate approximately 1000-1500 users, we used a c5a.12xlarge server boasting 48 vCPUs and 96GB of memory for JVB. After thorough server selection, we proceeded to install Jitsi Meet.

Simulating the Meeting:

At Meetrix, we leveraged our load testing mechanism, using bots to replicate real meeting scenarios with video-enabled users. Our objective was to identify when the meeting would encounter issues.

Upon setting up Jitsi Meet, we designated a dedicated meeting room (room name: load0) exclusively for this load test, populated with video-enabled bots.

In the initial phase, we incrementally added 50 bots at a time, reaching 250 participants. We closely monitored backend logs for any anomalies within Prosody, Jicofo, Nginx, and JVB. As we observed smooth functioning of core meeting features, we proceeded to the next phase.

In the second phase, we continued  increasing the bot count by 50 in each round until we reached 500 participants. Backend issues remained absent, and meeting functionality remained stable, although minor delays were noticed in button responsiveness.

Progressing to the third phase, we expanded the participant count to 750, still encountering no backend issues. However, the frontend showed signs of strain, including occasional video disruptions and increased latency.

Upon reaching 1000 participants in the fourth phase, server resource utilization, particularly in Prosody, increased. While the backend remained stable, the frontend experienced noticeable lag, with even basic operations such as opening the toolbar taking longer.

As we got close to 1250 participants in the last phase, frontend performance worsened. Lag and usability issues became prominent, signaling that we had reached the system's breaking point.

Conclusion:

In summary, our tests indicate that a single conference in Jitsi Meet can comfortably accommodate around 200-250 participants without encountering issues. It's important to note that the host machine's browser performance plays a pivotal role in determining this limit; superior browser performance may allow for more participants.

Most of the challenges encountered were associated with the frontend, as no substantial backend issues were recorded. This suggests that a single shard of Jitsi Meet can effectively manage up to 1000 participants, though the precise number may fluctuate depending on factors such as network conditions, vitrual hardware capabilities.

Hosting Multiple Conferences

Setting up the Environment

In our second approach, we employed Meetrix's terraform script for a rapid and low-overhead installation of a single shard setup. This setup consisted of a Jitsi Meet server (c6a.large), a Coturn server (t3a.micro), and a JVB autoscaling group (each utilizing c6a.xlarge). As mentioned in the previous approach, we continued choosing compute-optimized servers for both the meet server and JVB servers.

Simulating the Meeting:

In this approach, our goal was to host 100 meetings, each with approximately 10 participants. This allowed us to ensure that a single shard could effectively handle 1000 users, even with a substantial number of concurrent meetings. We employed the same load testing mechanism as before, though with a slightly lower count of video-enabled bots (75%) compared to the previous approach (100%).

We introduced around 100 bots into 10 conferences. In the first phase, while closely monitoring server and console logs, we scaled up to 500 users, thoroughly testing the core functionalities of the setup. With no reported issues, we progressed to the second phase, accommodating bots up to 1000 participants, and again observed smooth operation without encountering any issues. In the third and final phase, we added more bots, ultimately reaching approximately 1400 participants distributed across 100 concurrent meetings. We carefully ensured that meeting functions operated seamlessly across many meetings. At this stage, after achieving stability, Prosody appeared to consume nearly 20% of the CPU resources. Maintaining this configuration for several minutes without errors, we concluded the load test.

Conclusion:

In summary, our tests demonstrate that a single shard of Jitsi Meet can effectively manage 1000 participants without encountering any issues. It is advisable to utilize a CPU-optimized server for Jitsi Meet to maximize performance.

As we continue to explore the boundaries of virtual meetings, Jitsi Meet remains a robust solution with the potential for even greater scalability in the future.

References:

Approach 1:

Approach 2: