Wie viele Nutzer kann ein kleiner Plex-Server unterstützen?

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Ein kleiner Plex-Server kann viele registrierte Benutzer unterstützen, wenn nur wenige aktiv sind, während eine Handvoll gleichzeitiger Transkodierungen ihn schnell auslasten kann.

Die Anzahl der Konten verbraucht nicht dieselben Ressourcen wie die gleichzeitige Wiedergabe. Direct Play, die Konvertierung für Remote-Wiedergabe, die Upload-Bandbreite, die Untertitelverarbeitung und Hintergrundscans verändern den Ressourcenbedarf pro Sitzung. Erstelle anhand des tatsächlichen Verhaltens im Haushalt ein Szenario für die Spitzenlast und füge anschließend Benutzer hinzu, bis sich eine gemessene Ressource der Sättigungsgrenze nähert.

Gleichzeitige Sitzungen sind wichtiger als die Gesamtzahl der Konten

Zehn Konten mit zwei gleichzeitigen Direct-Play-Sitzungen können leichter zu bewältigen sein als drei Konten, die alle eine aufwendige 4K-Konvertierung auslösen. Entscheidend ist die aktive Arbeit, nicht die Anzahl der Benutzerkonten.

Videosysteme für mehrere Benutzer sind einer gemeinsam genutzten Bandbreitenkonkurrenz ausgesetzt, wenn sich die gleichzeitige Nachfrage der verfügbaren Kapazität am Netzwerkrand nähert. Deshalb muss die Überschneidung von Sitzungen Teil des Kapazitätsmodells sein.

Erfasse eine Woche lang die ausgelastetste Stunde und trenne lokale Direct-Play-, Remote-Direct-Play- und Transkodierungssitzungen. Verwende diese Verteilung als Lasttest, statt eine geschätzte „Anzahl der Streams pro Benutzer“ zu multiplizieren.

Transkodierung verändert den Rechenaufwand pro Benutzer

Ein einzelner inkompatibler Client kann Arbeit auf den Server verlagern, die mehrere kompatible Clients vermeiden würden. Hardwarebeschleunigung kann die Anzahl gleichzeitiger Konvertierungen verändern, die ein kleiner Prozessor bewältigen kann.

Ein sparsamer Intel N100 kann mehrere hardwarebeschleunigte Transkodierungssitzungen bewältigen, wenn seine Medien-Engine die Arbeitslast unterstützt. Dadurch verändert sich die Benutzerkapazität deutlich zwischen Direct Play und Szenarien mit intensiver Konvertierung.

Teste genau die Codecs, Untertitel, HDR-Bedingungen und Qualitätsgrenzen, die im Haushalt verwendet werden. Zähle ein Ergebnis mit Hardware-Transkodierung nicht, wenn ein gängiger Client-Pfad weiterhin auf Software-Transkodierung zurückfällt.

Remote-Benutzer teilen sich die Upload-Kapazität

Remote Direct Play kann die CPU nur gering belasten, aber dennoch mit derselben Upstream-Verbindung konkurrieren. Mehr CPU behebt keine WAN-Verbindung, die bereits nahe an ihrer Sättigungsgrenze arbeitet.

Die Methode zur Ermittlung der Ressourcensättigung gilt für den Netzwerkpfad ebenso wie für CPU oder Speicher: Anhaltende Warteschlangenbildung und Fehler sind wichtiger als eine einzelne Messung mit hoher Auslastung.

Führe gleichzeitige Remote-Sitzungen über ein externes Netzwerk aus und beobachte die Upload-Reserve. Der Remote-Streaming-Pfad sollte mit denselben Qualitätseinstellungen getestet werden, die die Benutzer tatsächlich auswählen.

-15% OFF

Hintergrundarbeiten verringern den sicheren Benutzerbereich

Bibliotheks-Scans, die Erstellung von Vorschauen, Backups und zusätzliche Container können sich mit der Wiedergabe überschneiden und dieselbe CPU, denselben Arbeitsspeicher und denselben Speicher beanspruchen. Kapazitätstests, die diese Aufgaben ignorieren, überschätzen die stabile Benutzerzahl.

Hintergrundarbeiten an Datenbank und Metadaten können bei großen Bibliotheken erhebliche CPU- und Speicherressourcen verbrauchen und dadurch den für die gleichzeitige Wiedergabe verfügbaren Spielraum verringern.

Wiederhole den Test mit der Spitzenbenutzerzahl, während geplante Aufgaben aktiv sind. Definiere den unterstützten Bereich als die höchste Last, die unter einem normalen Worst-Case-Szenario stabil bleibt, nicht als das beste Ergebnis eines im Leerlauf befindlichen Servers.

Tech- & KI-Zentrum

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.