Introduction:

Dans notre quête d'hébergement de grands rassemblements virtuels, nous avons voulu déterminer la capacité d'un seul fragment dans Jitsi Meet, en évaluant ses performances dans différents scénarios. Nous nous sommes concentrés sur deux approches de recherche distinctes : l'une consistait à héberger une seule conférence pour évaluer son point de rupture, tandis que l'autre explorait plusieurs conférences avec un faible nombre de participants dans chacune.

Organiser une conférence unique

Configuration de l'environnement

Nos recherches ont débuté par la configuration de notre environnement AWS. Nous avons déployé deux serveurs : l'un dédié à Jitsi Meet, incluant Prosody et Jicofo, et l'autre alloué au Jitsi Videobridge (JVB). Pour notre première phase de test, nous avons opté pour un serveur c6a.large, équipé de 2 vCPU et de 4 Go de mémoire. Étant donné la nature mono-thread de Prosody, nous avons sélectionné un serveur Compute Optimized avec seulement 2 cœurs pour gérer la tâche. Pour accueillir environ 1000 à 1500 utilisateurs, nous avons utilisé un serveur c5a.12xlarge doté de 48 vCPU et de 96 Go de mémoire pour JVB. Après une sélection minutieuse du serveur, nous avons procédé à l'installation de Jitsi Meet.

Simulation de la réunion :

Chez Meetrix, nous avons exploité notre mécanisme de test de charge, en utilisant des robots pour reproduire des scénarios de réunion réels avec des utilisateurs ayant accès à la vidéo. Notre objectif était d'identifier les moments où la réunion rencontrerait des problèmes.

Lors de la configuration de Jitsi Meet, nous avons désigné une salle de réunion dédiée (nom de la salle : load0) exclusivement pour ce test de charge, peuplée de robots compatibles vidéo.

Dans la phase initiale, nous avons ajouté progressivement 50 bots à la fois, pour atteindre 250 participants. Nous avons surveillé de près les journaux du backend pour détecter toute anomalie dans Prosody, Jicofo, Nginx et JVB. Comme nous avons constaté le bon fonctionnement des principales fonctionnalités de réunion, nous sommes passés à la phase suivante.

Au cours de la deuxième phase, nous avons continué à augmenter le nombre de robots de 50 à chaque tour jusqu'à atteindre 500 participants. Les problèmes de backend sont restés absents et la fonctionnalité des réunions est restée stable, bien que des retards mineurs aient été constatés dans la réactivité des boutons.

En passant à la troisième phase, nous avons augmenté le nombre de participants à 750, sans rencontrer de problèmes de back-end. Cependant, le front-end a montré des signes de fatigue, notamment des interruptions vidéo occasionnelles et une latence accrue.

Après avoir atteint 1 000 participants lors de la quatrième phase, l'utilisation des ressources du serveur, en particulier dans Prosody, a augmenté. Alors que le back-end est resté stable, le front-end a connu un ralentissement notable, même les opérations de base telles que l'ouverture de la barre d'outils prenant plus de temps.

Alors que nous approchions les 1 250 participants lors de la dernière phase, les performances du front-end se sont dégradées. Les problèmes de latence et d'utilisabilité sont devenus importants, signalant que nous avions atteint le point de rupture du système.

Conclusion:

En résumé, nos tests indiquent qu'une seule conférence dans Jitsi Meet sans aucune personnalisation peut accueillir confortablement environ 200 à 250 participants sans rencontrer de problèmes. Il est important de noter que les performances du navigateur de la machine hôte jouent un rôle essentiel dans la détermination de cette limite ; des performances de navigateur supérieures peuvent permettre d'accueillir plus de participants. Veuillez noter que si vous avez effectué des personnalisations du frontend, cela peut affecter les performances et la stabilité de la réunion, ce qui rend difficile l'atteinte de ces objectifs.

La plupart des difficultés rencontrées concernaient le front-end, car aucun problème majeur n'a été enregistré au niveau du back-end. Cela suggère qu'un seul fragment de Jitsi Meet peut gérer efficacement jusqu'à 1 000 participants, bien que le nombre précis puisse fluctuer en fonction de facteurs tels que les conditions du réseau et les capacités du matériel virtuel.

Organiser plusieurs conférences

Configuration de l'environnement

Dans notre deuxième approche, nous avons utilisé le script Terraform de Meetrix pour une installation rapide et peu coûteuse d'une configuration à un seul fragment. Cette configuration comprenait un serveur Jitsi Meet (c6a.large), un serveur Coturn (t3a.micro) et un groupe de mise à l'échelle automatique JVB (chacun utilisant c6a.xlarge). Comme mentionné dans l'approche précédente, nous avons continué à choisir des serveurs optimisés pour le calcul pour le serveur Meet et les serveurs JVB.

Simulation de la réunion :

Dans cette approche, notre objectif était d'organiser 100 réunions, chacune avec environ 10 participants. Cela nous a permis de garantir qu'un seul fragment pouvait gérer efficacement 1 000 utilisateurs, même avec un nombre important de réunions simultanées. Nous avons utilisé le même mécanisme de test de charge que précédemment, mais avec un nombre légèrement inférieur de robots compatibles vidéo (75 %) par rapport à l'approche précédente (100 %).

Nous avons introduit environ 100 bots dans 10 conférences. Dans la première phase, tout en surveillant de près les journaux du serveur et de la console, nous avons augmenté le nombre d'utilisateurs jusqu'à 500, en testant minutieusement les fonctionnalités de base de la configuration. Aucun problème n'a été signalé, nous sommes passés à la deuxième phase, en accueillant des bots jusqu'à 1000 participants, et avons de nouveau observé un fonctionnement fluide sans rencontrer de problèmes. Dans la troisième et dernière phase, nous avons ajouté davantage de bots, atteignant finalement environ 1400 participants répartis sur 100 réunions simultanées. Nous avons soigneusement veillé à ce que les fonctions de réunion fonctionnent de manière transparente dans de nombreuses réunions. À ce stade, après avoir atteint la stabilité, Prosody semblait consommer près de 20 % des ressources du processeur. En maintenant cette configuration pendant plusieurs minutes sans erreur, nous avons conclu le test de charge.

Conclusion:

En résumé, nos tests démontrent qu'un seul fragment de Jitsi Meet peut gérer efficacement 1 000 participants sans rencontrer de problèmes. Il est conseillé d'utiliser un serveur optimisé pour le processeur pour Jitsi Meet afin de maximiser les performances.

Alors que nous continuons d’explorer les limites des réunions virtuelles, Jitsi Meet reste une solution robuste avec le potentiel d’une évolutivité encore plus grande à l’avenir.

Références:

Approche 1 :

Approche 2 :

Si vous cherchez un soutien pour l'extension des limites de Jitsi Meet ou si vous avez besoin d'aide pour gérer plus de 1000 utilisateurs sur Jitsi, notre équipe est disponible pour un support commercial Jitsi. Nous sommes spécialisés dans l'optimisation des environnements Jitsi Meet pour les grands événements virtuels et pouvons vous aider avec l'optimisation des performances, les configurations personnalisées et les améliorations de la scalabilité. N'hésitez pas à nous contacter pour un conseil d'expert afin d'atteindre une performance optimale pour votre configuration. Contactez Meetrix à l'adresse hello@meetrix.io.