Wie viele gleichzeitige Nutzer kann Plex verarbeiten, bevor es langsamer wird?
Es gibt kein sinnvoll allgemeingültiges Plex-Benutzerlimit; Ihre stabile Parallelität ist die größte reale Sitzungskombination, die funktioniert, bevor Speicher, Netzwerk oder Transkodierung ihren Spielraum verlieren.
Zehn Benutzer mit Direct Play können weniger belastend sein als zwei anspruchsvolle Remote-Transkodierungen, und ein Server, der während der kontinuierlichen Wiedergabe ausreichend Reserven zu haben scheint, kann ins Stocken geraten, wenn mehrere Zuschauer gleichzeitig starten oder vorspulen. Berücksichtigen Sie die tatsächlichen Wiedergabemodi, Bitraten, Untertitel- und HDR-Pfade sowie die Upload-Nutzung durch Remote-Verbindungen. Fügen Sie dann repräsentative Sitzungen einzeln hinzu und stoppen Sie beim ersten reproduzierbaren Engpass, anstatt die Kapazität anhand des CPU-Modells oder der Anzahl der Konten zu schätzen.
Wiedergabepfade statt Konten zählen
Die Anzahl der Personen mit Plex-Zugriff entspricht nicht der Anzahl gleichzeitiger Arbeitslasten. Beobachten Sie zunächst den geschäftigsten realen Zeitraum und ordnen Sie jede aktive Sitzung Direct Play, Direct Stream, einer reinen Audiokonvertierung oder einer Videotranskodierung zu. Diese Modi beanspruchen die Serverressourcen sehr unterschiedlich.
Zehn oder mehr gleichzeitige Sitzungen können je nach Anzahl aktiver Direct-Play-, Remux-, Audiokonvertierungs- und Videotranskodierungspfade dennoch sehr unterschiedliche Grenzen ergeben. Eine bloße Benutzeranzahl kann den Punkt der Verlangsamung nicht vorhersagen.
Erstellen Sie ein Testszenario anhand der maximal plausiblen Überschneidung, nicht anhand der gesamten Haushalts- oder Freundesliste. Wenn sich sechs Benutzer selten überschneiden und alle Direct Play verwenden, ist das ein anderes Kapazitätsproblem als drei gleichzeitige 4K-Transkodierungen.
Ermitteln Sie die erste gemeinsame Ressource, die ihre Reserve verliert
Gleichzeitige Sitzungen teilen sich Medienspeicher, die Netzwerkschnittstelle des Servers, CPU-Leistung für Audio und Untertitel, temporären Transkodierungsspeicher sowie gegebenenfalls eine für die Konvertierung verwendete Hardware-Videoeinheit. Das Limit wird durch die benötigte Ressource festgelegt, die unter der tatsächlichen Mischung zuerst ausfällt – nicht durch die Komponente mit der höchsten technischen Kennzahl.
Hohe Plex-Arbeitslasten mit vielen gleichzeitigen Sitzungen können mehrere Engpässe bei Laufwerken, Netzwerk, Transkodierung und internen Datenpfaden sichtbar machen. Verwenden Sie dieselbe Betrachtung mehrerer Ressourcen auch bei kleineren Home-Servern.
Protokollieren Sie Medienfestplatten-Latenz, Netzwerkdurchsatz, CPU, GPU-Videoeinheiten, Speicherdruck und Transkodierungsgeschwindigkeit, während Sie Sitzungen einzeln hinzufügen. Die Kennzahl, die am selben Punkt wie die Wiedergabequalität wiederholt ihre Reserve verliert, markiert die praktische Kapazitätsgrenze.
Remote-Benutzer schaffen ein separates Upload-Limit
Lokale Streams können vollständig innerhalb eines schnellen LANs bleiben, während jeder Remote-Stream den Upload der Internetverbindung zu Hause mitbenutzt. Selbst ein leistungsstarker Server kann aus Sicht des Benutzers langsamer werden, wenn die kombinierten Original- oder Transkodierungsbitraten die verfügbare Upload-Kapazität überschreiten, die nach anderem Haushaltsverkehr übrig bleibt.
Bei der Remote-Kapazität müssen Netzwerk- und Transkodierungskapazität als separate Obergrenzen betrachtet werden. Eine schnellere GPU kann keine überlastete WAN-Uplink-Verbindung dazu bringen, mehr Daten zu übertragen.
Testen Sie die Remote-Parallelität von außerhalb des Hauses und nicht, indem Sie mehrere lokale Browser-Tabs öffnen. Wenn der Upload die erste Grenze darstellt, senken Sie die Remote-Bitraten oder verbessern Sie die Verbindung, bevor Sie eine leistungsfähigere CPU kaufen. Bleibt der Upload komfortabel und sinkt die Transkodierungsgeschwindigkeit, ist der Rechenpfad wahrscheinlich die stärkere Begrenzung.
Starts und Suchvorgänge machen Burst-Reserven sichtbar
Die kontinuierliche Wiedergabe ist oft weniger anspruchsvoll, als wenn mehrere Benutzer gleichzeitig starten oder vorspulen. In diesen Momenten entstehen Burst-Lesevorgänge, neue Puffer, Metadatenanfragen und neue Netzwerkverbindungen, bevor sich die Arbeitslast stabilisiert.
Eine feste Stream-Anzahl reicht für die Planung gleichzeitiger Transkodierungen nicht aus. Der Abnahmetest muss die Dateiformate, Zielbitraten, Untertitelpfade und Konvertierungsarbeiten umfassen, die gleichzeitig beginnen können.
Erfassen Sie die Zeit bis zum ersten Bild und die Erholung nach einem Suchvorgang, während die gewünschte Sitzungskombination bereits aktiv ist. Wenn nur synchronisierte Starts fehlschlagen, kann die Grenze durch Burst-Speicherzugriffe, Latenz im App-Zustand oder Warteschlangen entstehen und nicht durch die dauerhafte Rechenleistung.
Hintergrundaufgaben können dieselbe Reserve verringern
Scans, Backups, Downloads und Analyseaufgaben können dieselbe Speicher-, CPU-, Arbeitsspeicher- oder Netzwerkkapazität beanspruchen, die aktive Zuschauer benötigen. Ein Server, der einen Test in ruhiger Umgebung besteht, kann daher sein tatsächliches Haushaltsmaximum verfehlen.
Führen Sie die gewünschte Sitzungskombination einmal mit pausierter, nicht unbedingt erforderlicher Wartung und einmal mit einer repräsentativen Hintergrundaufgabe aus. Der Unterschied zeigt, ob eine andere Zeitplanung statt leistungsfähigerer Hardware die Reserve wiederherstellen kann.
Wenn die Wiedergabe auch bei pausierten Hintergrundaufgaben fehlschlägt, behalten Sie das Parallelitätslimit im Wiedergabepfad bei. Verschwindet der Fehler, planen Sie die konkurrierende Aufgabe um oder isolieren Sie sie und behalten Sie die kostengünstigere Serverbasis bei.
Halten Sie die Definitionen der erfolgreichen und fehlgeschlagenen Arbeitslast gemeinsam im Runbook fest. So bleibt das Betriebslimit reproduzierbar, wenn sich ein Client, Codec, Speicherpool oder geplanter Task ändert.
Ein Betriebslimit anhand eines wiederholten Tests festlegen
Ein sinnvolles Parallelitätslimit ist die wiederholt stabile Sitzungskombination und nicht die höchste Anzahl, die dreißig Sekunden lang funktioniert. Lassen Sie repräsentative Inhalte durch anspruchsvolle Szenen laufen, führen Sie einmal einen Suchvorgang aus und beobachten Sie das System lange genug, damit sich Temperaturen, Warteschlangen und Transkodierungsgeschwindigkeit stabilisieren.
Ein Test einer Remote-4K-Arbeitslast dimensioniert die Hardware erst, wenn Direct Play, Upload und Transkodierungsbedarf bekannt sind. So bleibt das Parallelitätslimit an gemessene Arbeitslasten statt an die Anzahl der Konten gebunden.
Dokumentieren Sie die erfolgreiche Sitzungskombination und den ersten Fehlermodus. Wenn ein weiterer Direct-Play-Stream das Netzwerk auslastet, basiert Ihr Limit auf dem Netzwerk. Wenn eine weitere Transkodierung unter Echtzeitgeschwindigkeit fällt, basiert es auf der Rechenleistung. Testen Sie nach größeren Änderungen an Client, Codec, Speicher oder Netzwerk erneut, statt die Zahl als dauerhaft zu betrachten.
Empfohlene Produkte
Support & Tipps
Mehr zum Lesen
Kann Plex eine GPU mit einem anderen Docker-Container gemeinsam nutzen?
Plex und ein weiterer Container können häufig auf dieselbe GPU zugreifen, aber du musst die Treiberunterstützung, die Gerätezuordnung, die Auslastung der Video-Engine, den Speicher...
So erkennst du, ob ein Plex-Fehler vom Client oder vom Server verursacht wird
Reproduziere dasselbe Element auf einem anderen Client, vergleiche den Sitzungspfad und sammle Serverbelege erst, nachdem der Geltungsbereich dir gezeigt hat, wo der Fehler tatsächlich...
So konfigurierst du den Plex-Cache und den temporären Transcodierungs-Speicher
Schütze den persistenten Plex-Zustand, indem du temporäre Transcodierungsdateien auf geeignetem lokalem Speicher ablegst, und überprüfe anschließend die Bereinigung, den freien Speicherplatz und das Verhalten...
