Einführung:

Auf unserem Weg, große virtuelle Versammlungen zu veranstalten, wollten wir die Kapazität eines einzelnen Shards in Jitsi Meet ermitteln und seine Leistung in verschiedenen Szenarien bewerten. Wir konzentrierten uns auf zwei unterschiedliche Forschungsansätze: Bei einem ging es darum, eine einzelne Konferenz zu veranstalten, um ihre Belastungsgrenze zu ermitteln, während bei dem anderen mehrere Konferenzen mit jeweils geringer Teilnehmerzahl untersucht wurden.

Ausrichten einer einzelnen Konferenz

Einrichten der Umgebung

Unsere Recherche begann mit der Konfiguration unserer AWS-Umgebung. Wir stellten zwei Server bereit: einen für Jitsi Meet, einschließlich Prosody und Jicofo, und den anderen für die Jitsi Videobridge (JVB). Für unsere erste Testphase entschieden wir uns für einen c6a.large-Server, der mit 2 vCPUs und 4 GB Arbeitsspeicher ausgestattet ist. Angesichts der Single-Thread-Natur von Prosody wählten wir für diese Aufgabe einen Compute Optimized-Server mit nur 2 Kernen. Um etwa 1000–1500 Benutzer unterzubringen, verwendeten wir einen c5a.12xlarge-Server mit 48 vCPUs und 96 GB Arbeitsspeicher für JVB. Nach einer gründlichen Serverauswahl begannen wir mit der Installation von Jitsi Meet.

Simulation des Meetings:

Bei Meetrix haben wir unseren Belastungstestmechanismus genutzt und mithilfe von Bots reale Besprechungsszenarien mit Benutzern mit Videofunktion nachgestellt. Unser Ziel war es, zu erkennen, wann es bei der Besprechung zu Problemen kommen würde.

Beim Einrichten von Jitsi Meet haben wir ausschließlich für diesen Belastungstest einen dedizierten Besprechungsraum (Raumname: load0) bestimmt, der mit videofähigen Bots gefüllt ist.

In der Anfangsphase haben wir schrittweise 50 Bots auf einmal hinzugefügt und so 250 Teilnehmer erreicht. Wir haben die Backend-Protokolle genau auf Anomalien in Prosody, Jicofo, Nginx und JVB überwacht. Als wir feststellten, dass die Kernfunktionen des Meetings reibungslos funktionierten, gingen wir zur nächsten Phase über.

In der zweiten Phase erhöhten wir die Bot-Anzahl in jeder Runde um 50, bis wir 500 Teilnehmer erreichten. Es traten keine Backend-Probleme mehr auf und die Meeting-Funktionalität blieb stabil, obwohl bei der Reaktion der Schaltflächen geringfügige Verzögerungen festgestellt wurden.

In der dritten Phase haben wir die Teilnehmerzahl auf 750 erhöht und dabei immer noch keine Backend-Probleme festgestellt. Das Frontend zeigte jedoch Anzeichen von Überlastung, darunter gelegentliche Videounterbrechungen und erhöhte Latenz.

Als in der vierten Phase 1000 Teilnehmer erreicht wurden, nahm die Serverressourcenauslastung, insbesondere bei Prosody, zu. Während das Backend stabil blieb, kam es beim Frontend zu spürbaren Verzögerungen, und selbst grundlegende Vorgänge wie das Öffnen der Symbolleiste dauerten länger.

Als wir in der letzten Phase fast 1250 Teilnehmer hatten, verschlechterte sich die Frontend-Leistung. Verzögerungen und Probleme mit der Benutzerfreundlichkeit traten deutlich zutage und signalisierten, dass wir die Belastungsgrenze des Systems erreicht hatten.

Abschluss:

Zusammenfassend zeigen unsere Tests, dass eine einzelne Konferenz in Jitsi Meet ohne jegliche Anpassungen problemlos etwa 200-250 Teilnehmer aufnehmen kann, ohne dass Probleme auftreten. Es ist wichtig zu beachten, dass die Browserleistung des Hostcomputers eine entscheidende Rolle bei der Bestimmung dieses Limits spielt; eine bessere Browserleistung kann mehr Teilnehmer ermöglichen. Bitte beachten Sie, dass sich Frontend-Anpassungen auf die Leistung und Stabilität des Meetings auswirken können, wodurch es schwierig wird, diese Ziele zu erreichen.

Die meisten der aufgetretenen Herausforderungen waren mit dem Frontend verbunden, da keine wesentlichen Backend-Probleme verzeichnet wurden. Dies lässt darauf schließen, dass ein einzelner Shard von Jitsi Meet bis zu 1000 Teilnehmer effektiv verwalten kann, obwohl die genaue Zahl je nach Faktoren wie Netzwerkbedingungen und virtuellen Hardwarefunktionen schwanken kann.

Mehrere Konferenzen veranstalten

Einrichten der Umgebung

Bei unserem zweiten Ansatz verwendeten wir das Terraform-Skript von Meetrix für eine schnelle und kostengünstige Installation eines einzelnen Shard-Setups. Dieses Setup bestand aus einem Jitsi Meet-Server (c6a.large), einem Coturn-Server (t3a.micro) und einer JVB-Autoscaling-Gruppe (jeweils mit c6a.xlarge). Wie im vorherigen Ansatz erwähnt, wählten wir weiterhin rechenoptimierte Server sowohl für den Meet-Server als auch für die JVB-Server.

Simulation des Meetings:

Bei diesem Ansatz war es unser Ziel, 100 Meetings mit jeweils etwa 10 Teilnehmern zu veranstalten. So konnten wir sicherstellen, dass ein einzelner Shard 1000 Benutzer effektiv bewältigen kann, selbst bei einer beträchtlichen Anzahl gleichzeitiger Meetings. Wir haben denselben Belastungstestmechanismus wie zuvor verwendet, allerdings mit einer etwas geringeren Anzahl videofähiger Bots (75 %) im Vergleich zum vorherigen Ansatz (100 %).

Wir haben etwa 100 Bots in 10 Konferenzen eingeführt. In der ersten Phase haben wir, während wir die Server- und Konsolenprotokolle genau überwachten, auf 500 Benutzer hochskaliert und die Kernfunktionen des Setups gründlich getestet. Da keine Probleme gemeldet wurden, gingen wir zur zweiten Phase über, in der wir Bots mit bis zu 1000 Teilnehmern unterbrachten, und stellten erneut einen reibungslosen Betrieb fest, ohne dass Probleme auftraten. In der dritten und letzten Phase haben wir weitere Bots hinzugefügt und erreichten schließlich etwa 1400 Teilnehmer, die auf 100 gleichzeitige Meetings verteilt waren. Wir haben sorgfältig sichergestellt, dass die Meeting-Funktionen bei vielen Meetings reibungslos funktionierten. In dieser Phase, nachdem Stabilität erreicht wurde, schien Prosody fast 20 % der CPU-Ressourcen zu verbrauchen. Wir haben diese Konfiguration mehrere Minuten lang ohne Fehler aufrechterhalten und den Belastungstest abgeschlossen.

Abschluss:

Zusammenfassend zeigen unsere Tests, dass ein einzelner Shard von Jitsi Meet 1000 Teilnehmer effektiv verwalten kann, ohne dass Probleme auftreten. Es ist ratsam, einen CPU-optimierten Server für Jitsi Meet zu verwenden, um die Leistung zu maximieren.

Während wir die Grenzen virtueller Meetings weiter ausloten, bleibt Jitsi Meet eine robuste Lösung mit dem Potenzial für noch größere Skalierbarkeit in der Zukunft.

Quellen:

Ansatz 1:

Ansatz 2:

Wenn Sie Unterstützung bei der Erweiterung des Jitsi Meet-Limits suchen oder Hilfe bei der Verwaltung von über 1000 Benutzern in Jitsi benötigen, steht Ihnen unser Team für kommerziellen Jitsi-Support zur Verfügung. Wir sind auf die Optimierung von Jitsi Meet-Umgebungen für virtuelle Großveranstaltungen spezialisiert und können bei der Leistungsoptimierung, benutzerdefinierten Konfigurationen und Skalierbarkeitsverbesserungen helfen. Kontaktieren Sie uns gerne für eine fachkundige Beratung zur Erzielung einer optimalen Leistung für Ihr Setup. Kontaktieren Sie Meetrix unter hello@meetrix.io.