Plattform → Lasttests

Janus-Lasttests

Wie viele Zuschauer ein einzelner Krona.Chat-Server bewältigt: Ergebnisse der Lasttests des Videoservers Janus.

Getestet am 10. Oktober 2026

Testserver
8 vCPUProzessor AMD EPYC 964516 GBArbeitsspeicher1 Gbit/sNetzwerkport1080pVideo mit ~2,5 Mbit/s
Gemischter ServerModels und Zuschauer auf einem Server bis 330 Zuschauer Das Model streamt auf diesen Server, und seine Zuschauer schauen vom selben Server aus zu. Die einfachste Architektur — ein Servertyp für alles.
Zuschauer-Servergetrennte Architektur bis 360 Zuschauer Mit ihm verbinden sich nur Zuschauer. Er erhält das Video der Models vom Model-Server und liefert es an die Zuschauer aus.
Model-Servergetrennte Architektur ~220 Übertragungen Mit ihm verbinden sich nur Models. Er empfängt ihre Übertragungen und leitet sie an die Zuschauer-Server weiter. Berechnet aus Messungen: Wir haben 120 Übertragungen getestet, dabei war der Server nur zu 14 % ausgelastet.

So funktionieren die Architekturen

Gemischt: Model → gemischter Server → Zuschauer dieses Models. Alle Zuschauer einer Übertragung müssen auf einen Server passen.

Getrennt (Kaskadierung): Model → Model-Server → ein oder mehrere Zuschauer-Server → Zuschauer. Die Weiterleitung des Videos zwischen den Servern (Kaskadierung) übernimmt der Model-Server selbst — ein separater Server ist dafür nicht nötig. Hat eine Übertragung viele Zuschauer, werden sie auf mehrere Zuschauer-Server verteilt.

Das Wichtigste in Kürze

  • Ein Server liefert Video zuverlässig an 330–360 Zuschauer gleichzeitig — ohne Ruckler und ohne Qualitätsverlust.
  • Wird der Empfang der Übertragungen auf einen separaten Server ausgelagert, bedient ein Zuschauer-Server etwa 10 % mehr Zuschauer als ein gemischter, und eine einzelne Übertragung kann beliebig viele Zuschauer haben — sie werden auf mehrere Zuschauer-Server verteilt.
  • Der Empfang der Übertragungen belastet den Server kaum. Die Hauptlast ist die Auslieferung des Videos an die Zuschauer.
  • Der Server nutzt seinen Netzwerkport fast vollständig: bis zu 900 Mbit/s Video an die Zuschauer ohne Verluste bei einem 1-Gbit/s-Port. Wird die Grenze überschritten, sinkt die Qualität sofort für alle. Deshalb werden Server mit Reserve ausgelastet — genau so rechnet auch der Rechner unten auf der Seite.

So haben wir getestet

Getestet wurden die Videoserver von Krona.Chat. Models und Zuschauer waren Software-Clients, die sich wie ein Browser verhalten: Sie betreten einen Raum, senden und empfangen Video.

  1. Übertragungen starten

    Die Models beginnen, 1080p-Video mit etwa 2,5 Mbit/s zu streamen — wie eine echte Webcam.

  2. Zuschauer hinzufügen

    Alle 2 Sekunden verbindet sich ein neuer Zuschauer — die Last steigt gleichmäßig.

  3. Qualität beobachten

    Für jeden Zuschauer messen wir, wie viel Video unterwegs verloren geht. Solange der Verlust unter 1 % liegt, ist das Bild flüssig.

  4. Grenze ermitteln

    Der Test endet, sobald die Qualität nachlässt. Die höchste Zuschauerzahl ohne Verluste ist die Kapazität des Servers.

Jede Architektur wurde in einem eigenen Test geprüft. Jede Linie in den Diagrammen ist ein eigener Test; die Linien addieren sich nicht.

Ergebnisse

Wie viel Video der Server an die Zuschauer sendet

Je mehr Zuschauer, desto mehr Video sendet der Server. Solange die Linie gleichmäßig steigt, erhält jeder Zuschauer das vollständige Video. Knickt die Linie nach unten ab, ist der Server überlastet und kann nicht mehr allen das Video ausliefern.

Tabelle anzeigen

Mbit/s — wie viel Video der Server pro Sekunde an alle Zuschauer sendet. Grüner Rahmen — die höchste Zuschauerzahl ohne Qualitätsverlust; roter Hintergrund — Überlast.

Videoqualität bei den Zuschauern

Der Anteil des Videos, der den Zuschauer nicht erreicht hat. Bis 1 % bemerkt der Zuschauer das nicht; darüber stockt das Bild und zerfällt. Ein sprunghafter Anstieg der Verluste markiert die Grenze des Servers.

Tabelle anzeigen

Videoverluste bei den Zuschauern, %. Grüner Rahmen — die höchste Zuschauerzahl ohne Qualitätsverlust; roter Hintergrund — Überlast.

CPU-Auslastung des Servers

Die CPU erreicht nie 100 %: Der Server stößt vorher an die Grenze der Videoauslieferung. Nach Überschreiten der Grenze sinkt die Auslastung sogar — der Server verliert Video, statt es zu senden.

Tabelle anzeigen

CPU-Auslastung, %. Grüner Rahmen — die höchste Zuschauerzahl ohne Qualitätsverlust; roter Hintergrund — Überlast.

Welche Architektur passt

Alle Werte gelten für 1080p-Video mit etwa 2,5 Mbit/s ohne Qualitätsverlust.

Gemischter Server

bis 330 Zuschauer

Models und ihre Zuschauer auf einem Server. Im Test hatte jede Übertragung etwa 33 Zuschauer.

Geeignet für Übertragungen mit bis zu einigen Hundert Zuschauern. Bei vielen Übertragungen mit jeweils wenigen Zuschauern (etwa 10) schafft der Server etwas weniger — etwa 280.

Getrennte Architektur

bis 360 Zuschauer

Model-Server empfangen die Übertragungen, Zuschauer-Server zeigen sie. Ein Zuschauer-Server bedient etwa 10 % mehr Zuschauer als ein gemischter.

Geeignet für ein großes Publikum: Die Zuschauer einer Übertragung werden auf mehrere Zuschauer-Server verteilt, die Grenze „das ganze Publikum auf einem Server“ entfällt.

Model-Server

~220 Übertragungen

Teil der getrennten Architektur: Er empfängt das Video der Models und leitet es an die Zuschauer-Server weiter. Das ist leichte Arbeit: 120 Übertragungen lasteten den Server nur zu 14 % aus.

~220 ist aus Messungen berechnet: Für diesen Server bedeutet jede Übertragung ein eingehendes Video und eine Weiterleitung.

Vergleich mit dem Rechner auf der Website

Der Serverrechner auf der Website geht von etwa 700 Mbit/s Video an die Zuschauer pro Server aus. Der Test hat gezeigt, dass ein Server mit 1-Gbit/s-Port bis zu 900 Mbit/s ohne Verluste ausliefert — der Rechner auf der Website kalkuliert also mit großzügiger Reserve.

Bei Video mit 2,5 Mbit/s sind das 330–360 Zuschauer pro Server. Bei 1080p mit 3 Mbit/s sind es rechnerisch etwa 290 Zuschauer.

Eine Berechnung, kein Testergebnis

Rechner: Wie viele Server Sie brauchen

Er verwendet die Koeffizienten aus unseren Tests. Geben Sie Ihre Last und den Serverpreis bei Ihrem Anbieter ein.

Benötigte Server—
Kosten pro Monat—
Zuschauer gesamt—gleichzeitig
Zuschauer pro Server—

Die Ergebnisse wurden auf einem Testserver ermittelt und können je nach Anbieter, Netzwerk und Einstellungen der Übertragungen abweichen.

Der Bericht wurde mit orchestration/capacity_report.py aus den Daten der Testläufe erstellt (Locust + Prometheus + RTP-Statistik der Zuschauer).