Wie viele Benutzer kann Jellyfin auf einem kleinen Heimserver unterstützen?

Für einen kleinen Jellyfin-Server gibt es keine seriöse feste Nutzerzahl, da gleichzeitige Wiedergabepfade und Bitraten weit wichtiger sind als registrierte Konten.

Zehn Familienprofile, die sich selten überschneiden, können einfacher zu bewältigen sein als zwei gleichzeitige Nutzer, deren Clients 4K-Tonemapping, das Einbrennen von Untertiteln und die Umwandlung der Bitrate für die Remote-Wiedergabe erzwingen. Die Kapazität sollte daher anhand gleichzeitiger Workload-Einheiten vorhergesagt werden: Direct-Play-Sitzungen, Remuxes, Audiokonvertierungen, Videotranscodierungen, Hintergrundaufgaben und der Bandbreitenbedarf für die Remote-Wiedergabe. Die kleinste Ressourcenreserve unter diesen Faktoren legt die praktische Obergrenze der Nutzerzahl fest.

Registrierte Nutzer sind nicht dasselbe wie gleichzeitige Auslastung

Ein Jellyfin-Konto verbraucht im Leerlauf nahezu keine nennenswerte Wiedergabekapazität. Die Serverlast entsteht, wenn Nutzer Inhalte durchsuchen, streamen, transcodieren, scannen oder Metadaten aktualisieren und sich diese Aktionen zeitlich überschneiden. Die Planung anhand der Gesamtzahl der Haushaltskonten verwechselt daher Identitätsverwaltung mit Gleichzeitigkeit. Entscheidend ist die Anzahl der gleichzeitig ausgeführten aufwendigen Vorgänge während der üblichen Spitzenzeit.

Der Bandbreitenleitfaden von ZimaSpace modelliert den Remote-Bedarf anhand der Bitraten gleichzeitig ausgelieferter Streams und nicht anhand der Kontenzahl. Dieses Modell gleichzeitiger Streams lässt sich auf den gesamten Server übertragen: Zähle aktive Workloads und ihre Ressourcenpfade und plane anschließend Reserve für Lastspitzen ein, statt einen CPU-Benchmark durch eine geschätzte Personenzahl zu teilen.

Die Grenze liegt in der Verhaltensvariabilität. In einem Haushalt kann die Überschneidung am Abend vorhersehbar sein, während der gemeinsame Zugriff durch viele Remote-Nutzer zu unregelmäßigeren Lastspitzen führen kann. Verwende nach Möglichkeit beobachtete Spitzenwerte und andernfalls einen konservativ geplanten Spitzenwert. Zähle nicht jedes registrierte Konto als gleichzeitig aktiv, außer dies entspricht tatsächlich den Anforderungen des Dienstes.

Bei Direct-Play-Nutzern sind zunächst meist Speicher und Netzwerk der begrenzende Faktor

Wenn Clientgeräte die Quelldateien unterstützen, wird jede Direct-Play-Sitzung im Wesentlichen zu einer Lese- und Netzwerkbelastung. Die CPU-Auslastung kann niedrig bleiben, sodass ein kleiner Server mehrere solcher Sitzungen bewältigen kann, bis die aggregierte Medienbitrate, die Festplattenparallelität oder die Netzwerkkapazität keine ausreichende Reserve mehr lässt. Die genaue Anzahl hängt von 1080p- gegenüber hochbitratigen 4K-Dateien sowie von lokaler gegenüber entfernter Wiedergabe ab.

Jellyfins Hardwareleitfaden betont, dass der Medienspeicher bei gewöhnlicher Wiedergabe lediglich eine sequenzielle Geschwindigkeit oberhalb der erforderlichen Bitrate benötigt, während das Netzwerk die ausgelieferten Streams übertragen muss. Der Ressourcenpfad für Direct Play erklärt, warum ein Gerät mit geringem Stromverbrauch mehr kompatible Nutzer bedienen kann, als seine CPU-Klasse vermuten lässt, sofern Speicher und Netzwerk deutlich unter ihrer Sättigungsgrenze bleiben.

Die Grenze ist die Spitzenbitrate, nicht die durchschnittliche Dateigröße. Medien mit variabler Bitrate können über den Durchschnitt hinausgehende Spitzen erzeugen, und mehrere unabhängige Streams können gleichzeitig Suchvorgänge ausführen. Plane Reserve ein, anstatt die Verbindung oder den Datenträger bis zum theoretischen Maximum auszulasten, und überprüfe anschließend die tatsächlichen Dateien mit der höchsten Bitrate, die der Haushalt gleichzeitig abspielen möchte.

Transcoding-Nutzer beanspruchen einen anderen Kapazitätspool

Eine Videotranscodierung umfasst Dekodierung, Filterung, Tonemapping oder Untertitelkomposition, Enkodierung und temporäre Segment-E/A. Hardwarebeschleunigung kann dies effizient gestalten, doch unterstützte Codecs, die Generation der Engine, der Treiberzugriff, Ausgabeeinstellungen und die gleichzeitige Nutzung der Engine bestimmen, wie viele Streams über Echtzeitgeschwindigkeit bleiben. Ein einziger Software-Fallback kann mehr CPU verbrauchen als mehrere Direct-Play-Nutzer zusammen.

Der Leitfaden zur Hardwaretranscodierung macht diesen Unterschied ausdrücklich deutlich: Die Videokonvertierung ausschließlich per CPU kann äußerst anspruchsvoll sein, während geeignete Medienengines unterstützte Pfade wesentlich effizienter verarbeiten. Daher muss die „Nutzerzahl“ eines kleinen Servers in günstige Direct-Play-Sitzungen und aufwendige Konvertierungssitzungen aufgeteilt werden, anstatt sie zu einer einzigen Zahl zu mitteln.

Die Ausfallgrenze liegt bei der anhaltenden Transcodierungsgeschwindigkeit und dem Wachstum der Warteschlange. Zähle einen weiteren Transcoding-Nutzer nur dann, wenn jeder repräsentative Stream auch nach mehreren Minuten und unter der normalen thermischen Belastung oberhalb der Echtzeit bleibt. Fällt ein Pfad auf Softwareverarbeitung zurück oder unter die Echtzeitgeschwindigkeit, muss sein Kapazitätsbeitrag separat neu berechnet werden, statt ihn im Durchschnitt zu verbergen.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Hintergrunddienste und der Cache-Zustand verändern dieselbe Nutzerzahl

Bibliotheksscans, Backups, Downloader, Fotoindizierung und andere Container können die für dieselbe Anzahl von Zuschauern verfügbare Reserve verringern. Ein leerer Cache macht auch das erstmalige Durchsuchen und die Metadatenverarbeitung aufwendiger als wiederholte Anfragen bei warmem Cache. Ein Kapazitätstest auf einem im Leerlauf befindlichen Server mit warmem Cache kann daher überschätzen, was der Haushalt während der tatsächlichen Spitzenzeit am Abend erlebt.

Die Analyse von ZimaSpace zu Service-Stacks weist darauf hin, dass Container zwar getrennte Lebenszyklusgrenzen besitzen, sich aber weiterhin CPU, RAM, Speicher und Beschleuniger des Hosts teilen. Dieses Modell gemeinsam genutzter Ressourcen erklärt, warum benachbarte Dienste in einen realistischen Kapazitätstest gehören: Sie können den ersten Engpass vom Netzwerk oder der Transcodierung auf Speicherwarteschlangen oder Speicherdruck verlagern, ohne einen weiteren Jellyfin-Nutzer hinzuzufügen.

Die Grenze ist die erforderliche Koexistenz. Wenn ein Backup sicher außerhalb des Wiedergabezeitfensters geplant werden kann, sollte es keinen größeren Jellyfin-Host erzwingen. Wenn die Fotoindizierung oder ein anderer Dienst jedoch dauerhaft parallel laufen muss und wiederholt dieselbe Ressource sättigt, gehört dieser Bedarf in den Kapazitätsrahmen, da seine Entfernung die tatsächlichen Anforderungen an den Heimserver verändern würde.

Wandle den Haushalt in Workload-Einheiten um und füge Nutzer hinzu, bis die Reserve aufgebraucht ist

Erstelle aus der tatsächlichen Spitzenmischung eine Workload-Einheit, zum Beispiel zwei lokale Direct-Plays, eine Remote-Transcodierung und den Hintergrunddienst, der normalerweise gleichzeitig läuft. Miss die Zeit bis zum ersten Bild, Pufferungen, Transcodierungsgeschwindigkeit, CPU- oder GPU-Sättigung, Speicherdruck, Speicherlatenz und Netzwerkdurchsatz. Füge jeweils eine repräsentative Sitzung hinzu und behalte Medien und Clients konstant, damit die zuerst ausfallende Ressource eindeutig zugeordnet werden kann.

Die Methode zur Ermittlung von Ressourcensättigung liefert die Entscheidungsregel: Achte bei jeder Ressource auf Auslastung, Sättigung und Fehler, statt eine einzelne Kennzahl hervorzuheben. Wenn eine Warteschlange wiederholt auftritt, bevor die Wiedergabe ihre Frist verfehlt, legt diese Warteschlange die Gleichzeitigkeit der aktuellen Konfiguration fest. Ein anderer CPU-Wert setzt den beobachteten Engpass nicht außer Kraft.

Gib die Kapazität als Workload-Aussage und nicht als universelle Nutzerzahl an: „Dieser Server bewältigt diese Kombination aus Clients und Medien mit dieser Reserve.“ Halte den Produktivbetrieb eine Stufe unterhalb des ersten reproduzierbaren Fehlers und teste erneut, wenn sich Codecs, Clients, Speicher, Netzwerk oder Hintergrunddienste ändern. Diese Antwort bleibt auch bei einer veränderten Zahl registrierter Nutzer aussagekräftig, da sie an den tatsächlichen gleichzeitigen Bedarf gebunden ist.