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.
Approche 1 : 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.
Phase 1 : 250 participants
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.
Phase 2 : 500 participants
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.
Phase 3 : 750 participants
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.
Phase 4 : 1000 participants
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.
Phase 5 : 1250 participants - Point de rupture
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 - Approche 1
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.
Approche 2 : 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 %).
Phase 1 : 500 participants (50 réunions)
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.
Phase 2 : 1000 participants (100 réunions)
En accueillant des bots jusqu'à 1000 participants, nous avons de nouveau observé un fonctionnement fluide sans rencontrer de problèmes. Les fonctionnalités de réunion ont continué à fonctionner de manière transparente dans toutes les réunions simultanées.
Phase 3 : 1400 participants (100+ réunions)
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 - Approche 2
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.
Cette approche s'est révélée plus efficace que l'hébergement d'une seule grande conférence, permettant une meilleure répartition de la charge et une expérience utilisateur plus stable.
Recommandations techniques
| Composant | Configuration recommandée | Justification |
|---|---|---|
| Serveur Jitsi Meet | c6a.large (2 vCPU, 4 Go) | Optimisé pour la nature mono-thread de Prosody |
| Jitsi Videobridge | c5a.12xlarge (48 vCPU, 96 Go) | Gestion efficace de 1000+ flux vidéo |
| Serveur Coturn | t3a.micro | Suffisant pour la traversée NAT |
| Architecture recommandée | Plusieurs petites conférences | Meilleure performance que les grandes conférences uniques |
Facteurs influençant les performances
- Performances du navigateur : Un facteur critique pour l'expérience utilisateur
- Conditions réseau : Latence et bande passante disponible
- Personnalisations frontend : Peuvent impacter négativement les performances
- Configuration matérielle : Serveurs optimisés pour le calcul recommandés
- Répartition des utilisateurs : Plusieurs petites conférences vs une grande conférence
Références
Approche 1 :
Approche 2 :
Conclusion générale
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. Nos tests démontrent clairement que :
- Jitsi Meet peut gérer efficacement 1000+ utilisateurs simultanés
- La répartition sur plusieurs conférences est plus efficace qu'une seule grande conférence
- Les serveurs optimisés pour le calcul sont essentiels pour les performances
- Le frontend constitue généralement le goulot d'étranglement principal
Frequently Asked Questions
Quelle est la limite recommandée d'utilisateurs pour une seule conférence Jitsi ?
Nos tests indiquent qu'une seule conférence Jitsi peut accueillir confortablement environ 200 à 250 participants sans rencontrer de problèmes majeurs, bien que cela dépende des performances du navigateur et des personnalisations.
Jitsi peut-il gérer 1000 utilisateurs simultanés ?
Oui, Jitsi peut gérer 1000 utilisateurs simultanés, mais il est plus efficace de les répartir sur plusieurs conférences plutôt que dans une seule salle de réunion.
Quels sont les principaux goulots d'étranglement lors de l'augmentation du nombre d'utilisateurs ?
Les principaux défis concernent le front-end (performances du navigateur) plutôt que le back-end. Les problèmes incluent la latence accrue, les interruptions vidéo et la lenteur de l'interface utilisateur.
Quelle configuration serveur recommandez-vous pour 1000+ utilisateurs ?
Nous recommandons des serveurs optimisés pour le calcul : c6a.large pour Jitsi Meet (2 vCPU, 4 Go) et c5a.12xlarge pour JVB (48 vCPU, 96 Go) pour gérer efficacement 1000+ utilisateurs.
Besoin d'aide pour optimiser votre infrastructure Jitsi ?
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é.
Contactez Meetrix
