Hoeveel gebruikers kan Jellyfin ondersteunen op een kleine homeserver?

Er bestaat geen eerlijk vast aantal gebruikers voor een kleine Jellyfin-server, omdat gelijktijdige afspeelpaden en bitrates veel belangrijker zijn dan geregistreerde accounts.

Tien gezinsprofielen die zelden overlappen, kunnen eenvoudiger zijn dan twee gelijktijdige gebruikers van wie de clients 4K-tonemapping, het inbranden van ondertitels en conversie van de bitrate op afstand afdwingen. De capaciteit moet daarom worden voorspeld aan de hand van gelijktijdige werklasteenheden: Direct Play-sessies, remuxes, audioconversies, videotranscoderingen, achtergrondtaken en de benodigde bandbreedte op afstand. De kleinste resource-marge bepaalt de praktische bovengrens voor het aantal gebruikers.

Geregistreerde gebruikers zijn niet hetzelfde als gelijktijdige werklast

Een Jellyfin-account verbruikt vrijwel geen noemenswaardige afspeelcapaciteit wanneer het inactief is. De serverbelasting ontstaat wanneer gebruikers bladeren, streamen, transcoderen, scannen of metadata bijwerken, en deze acties elkaar in de tijd overlappen. Plannen op basis van het totale aantal gezinsaccounts verwart identiteitsbeheer daarom met gelijktijdigheid. Het relevante aantal is het aantal gelijktijdige veeleisende bewerkingen tijdens de drukste normale periode.

De bandbreedtegids van ZimaSpace modelleert de vraag op afstand aan de hand van de bitrates van gelijktijdig geleverde streams, niet aan de hand van het aantal accounts. Dit model voor gelijktijdige streams kan worden doorgetrokken naar de hele server: tel actieve werklasten en hun resourcepaden, en voeg vervolgens marge toe voor pieken, in plaats van een CPU-benchmark te delen door een geschat aantal personen.

De grens wordt bepaald door variatie in gedrag. Een huishouden kan voorspelbare overlap in de avond hebben, terwijl gedeelde toegang door veel gebruikers op afstand tot grilligere pieken kan leiden. Gebruik waar mogelijk waargenomen pieksessies en anders een conservatieve geplande piek; tel niet elk geregistreerd account als gelijktijdig, tenzij dat daadwerkelijk de vereiste van de dienst is.

Direct Play-gebruikers worden meestal eerst beperkt door opslag en netwerk

Wanneer clientapparaten de bronmedia ondersteunen, wordt elke Direct Play-sessie grotendeels een lees- en netwerkbelasting. Het CPU-gebruik kan bescheiden blijven, waardoor een kleine server meerdere van zulke sessies kan verwerken totdat de totale mediabitrate, gelijktijdige schijftoegang of netwerkcapaciteit onvoldoende marge overlaat. Het precieze aantal verandert afhankelijk van 1080p-bestanden versus 4K-bestanden met een hoge bitrate, en van lokale versus externe levering.

De hardwarehandleiding van Jellyfin benadrukt dat mediaopslag voor normale weergave alleen een sequentiële snelheid boven de vereiste bitrate nodig heeft, terwijl het netwerk de geleverde streams moet kunnen dragen. Het resourcepad voor Direct Play verklaart waarom een energiezuinige machine meer compatibele gebruikers kan bedienen dan zijn CPU-klasse doet vermoeden, zolang opslag en netwerk comfortabel onder verzadiging blijven.

De grens wordt bepaald door de piekbitrate, niet door de gemiddelde bestandsgrootte. Media met variabele bitrate kan boven het gemiddelde uitkomen en meerdere onafhankelijke streams kunnen tegelijk zoeken. Houd marge aan in plaats van de verbinding of schijf tot de theoretische maximumcapaciteit te vullen, en valideer dit vervolgens met de bestanden met de hoogste bitrate die het huishouden gelijktijdig verwacht af te spelen.

Gebruikers die transcoderen verbruiken een andere capaciteitspool

Een videotranscodering voegt decodering, filtering, tonemapping of het samenstellen van ondertitels, codering en tijdelijke segment-I/O toe. Hardwareversnelling kan dit efficiënt maken, maar ondersteunde codecs, de generatie van de engine, toegang tot stuurprogramma’s, uitvoerinstellingen en gelijktijdig enginegebruik bepalen hoeveel streams sneller dan in realtime verwerkt blijven worden. Eén terugval naar software kan meer CPU verbruiken dan meerdere Direct Play-gebruikers samen.

De richtlijnen voor hardwaretranscodering maken dit onderscheid expliciet: videoconversie die uitsluitend op de CPU draait, kan extreem veeleisend zijn, terwijl geschikte media-engines ondersteunde paden veel efficiënter verwerken. Daarom moet het “aantal gebruikers” van een kleine server worden opgesplitst in goedkope Direct Play-sessies en dure conversiesessies, in plaats van tot één gemiddelde waarde te worden samengevoegd.

De faalgrens is een aanhoudende transcodeersnelheid en groei van de wachtrij. Tel een extra gebruiker die transcodeert alleen mee als elke representatieve stream na enkele minuten en bij de normale thermische toestand sneller dan in realtime blijft. Als een pad terugvalt naar software of onder realtime zakt, moet de capaciteitsbijdrage daarvan afzonderlijk opnieuw worden berekend in plaats van in het gemiddelde te worden verborgen.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Achtergrondservices en de cachetoestand veranderen hetzelfde gebruikersaantal

Bibliotheคscans, back-ups, downloaders, foto-indexering en andere containers kunnen de marge voor hetzelfde aantal kijkers verkleinen. Een lege cache maakt het eerste bladeren en metadatawerk bovendien zwaarder dan herhaalde aanvragen met een warme cache. Een capaciteitstest op een inactieve server met een warme cache kan daardoor overschatten wat het huishouden tijdens de echte avondpiek ervaart.

De analyse van de servicestack van ZimaSpace merkt op dat containers afzonderlijke levenscyclusgrenzen behouden, maar nog steeds CPU, RAM, opslag en accelerators van de host delen. Het model van gedeelde resources verklaart waarom aangrenzende services deel moeten uitmaken van een realistische capaciteitstest: ze kunnen de eerste bottleneck verplaatsen van netwerk of transcodering naar wachtrijen bij opslag of geheugendruk, zonder een extra Jellyfin-gebruiker toe te voegen.

De grens wordt bepaald door noodzakelijke gelijktijdigheid. Als een back-up veilig buiten het kijkvenster kan worden gepland, hoeft die geen grotere Jellyfin-host af te dwingen. Als foto-indexering of een andere service continu moet overlappen en herhaaldelijk dezelfde resource verzadigt, hoort die vraag binnen de capaciteitsgrens, omdat het verwijderen ervan de werkelijke vereisten van de thuisserver zou veranderen.

Zet het huishouden om in werklasteenheden en voeg gebruikers toe totdat de marge verdwijnt

Maak één werklasteenheid op basis van de werkelijke piekmix, bijvoorbeeld twee lokale Direct Plays, één transcodering op afstand en de achtergrondservice die normaal overlapt. Meet de tijd tot het eerste beeld, buffering, transcodeersnelheid, CPU- of GPU-verzadiging, geheugendruk, opslaglatentie en netwerkdoorvoer. Voeg steeds één representatieve sessie toe en houd media en clients constant, zodat de eerste falende resource kan worden aangewezen.

De methode voor resourceverzadiging levert de beslisregel: kijk naar gebruik, verzadiging en fouten op elke resource, in plaats van één hoofdmetriek te kiezen. Wanneer een bepaalde wachtrij herhaaldelijk verschijnt voordat het afspelen de deadline mist, bepaalt die wachtrij de gelijktijdigheidsgrens van de huidige configuratie; een andere CPU-score verandert niets aan de waargenomen bottleneck.

Publiceer de capaciteit als een werklastbeschrijving, niet als een universeel gebruikersaantal: “deze server slaagt voor deze client- en mediamix met deze marge.” Houd de productie één stap onder de eerste herhaalbare fout en test opnieuw na wijzigingen aan codecs, clients, opslag, netwerk of achtergrondservices. Dit antwoord blijft nuttig, ook als het aantal geregistreerde gebruikers verandert, omdat het is gekoppeld aan de werkelijke gelijktijdige vraag.