Quanti utenti e attività in background dovrebbe supportare un host Jellyfin?

Un host Jellyfin non dovrebbe essere dimensionato contando solo gli utenti registrati. Un nucleo familiare con otto account può generare meno carico di due spettatori remoti che effettuano la transcodifica di video 4K mentre una scansione della libreria, un'attività sui sottotitoli e un backup vengono eseguiti in background. La domanda utile sulla capacità è quanta attività simultanea in primo piano e in background l'host riesca ad assorbire prima che la riproduzione o l'amministrazione smettano di rispettare l'obiettivo prefissato.

Costruisci un unico budget del carico di lavoro che includa sessioni di riproduzione, transcodifiche, attività pianificate, attività di archiviazione e servizi ospitati insieme. Poi testa la sovrapposizione normale più intensa e smetti di aumentare il carico quando la prima risorsa condivisa sviluppa una coda persistente, errori o ritardi visibili all'utente.

Trasforma gli utenti in carichi di riproduzione

Conta separatamente le sessioni di Direct Play, remux, conversione audio e transcodifica video. I client Jellyfin comunicano i codec, le risoluzioni, i bitrate e i vincoli supportati, quindi due utenti che guardano la stessa sorgente possono chiedere al server di svolgere attività molto diverse.

Le politiche utente di Jellyfin possono inoltre modificare la domanda sul server. Gli attuali controlli di gestione degli utenti possono consentire o limitare l'accesso remoto, la riproduzione dei contenuti multimediali, la transcodifica e il bitrate Internet per flusso. Il numero di utenti diventa quindi utile solo dopo essere stato tradotto nelle autorizzazioni e nelle modalità di riproduzione previste nello stesso momento.

Inizia dalla combinazione normale più impegnativa di una serata, invece che dal numero massimo teorico di account. Se in casa ci sono normalmente due sessioni locali in Direct Play e una conversione remota, questo è il carico di base che l'host deve gestire agevolmente.

Aggiungi le attività pianificate allo stesso budget di capacità

Jellyfin esegue attività anche quando nessuno preme Play. Le scansioni della libreria, i download dei sottotitoli, la pulizia della cache, gli aggiornamenti dei plugin, l'estrazione delle immagini dei capitoli, l'ottimizzazione del database e le attività di generazione dei contenuti multimediali possono sovrapporsi alla visione.

L'attuale elenco delle attività pianificate mostra che Jellyfin può eseguire scansioni, estrazione di immagini, aggiornamenti dei plugin, manutenzione del database, attività sui sottotitoli, pulizia della cache e altri lavori in background. I plugin possono aggiungere ulteriori attività.

Non dimensionare il server sulla base di un benchmark di riproduzione eseguito in condizioni tranquille, per poi lasciare che ogni attività pesante venga eseguita durante lo stesso picco. Sposta prima le attività rinviabili al di fuori della finestra di visione; includi nel test di produzione quelle che devono sovrapporsi.

Individua la prima risorsa condivisa che perde margine

Un host può cedere per la capacità del motore multimediale, la CPU, la memoria, la latenza dell'SSD, la pressione delle operazioni di ricerca sugli HDD, la larghezza di banda di rete o una dipendenza. Un numero maggiore di core CPU non aiuta quando un collegamento remoto in upload è saturo, così come una quantità maggiore di RAM non risolve una transcodifica che la GPU selezionata non è in grado di accelerare.

L'analisi di ZimaSpace sulla capacità di Jellyfin su un piccolo server domestico utilizza lo stesso modello basato prima sul carico di lavoro: la domanda simultanea e la prima risorsa satura contano più di un limite basato sul numero di account.

Misura la velocità di transcodifica, la saturazione della CPU o del motore multimediale, la pressione sulla memoria, la latenza dello storage e il throughput di rete durante la sovrapposizione esatta. La risorsa limitante è quella la cui pressione aumenta insieme al problema e migliora quando tale pressione viene rimossa.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Impedisci alle attività in background di consumare il margine interattivo

La riproduzione ha una scadenza: il segmento successivo deve arrivare prima che il buffer del client si svuoti. Una scansione della libreria può generalmente terminare più tardi senza danneggiare l'esperienza di nessuno. Questa differenza dovrebbe determinare la pianificazione e le politiche delle risorse.

Riserva margine sufficiente affinché l'avvio o il salto durante una riproduzione normale restino reattivi mentre le attività inevitabili in background continuano. Se un'ottimizzazione del database o un'attività di analisi dei contenuti multimediali causa buffering, pianificala diversamente oppure limita l'attività prima di acquistare un server più grande.

Su un host condiviso, ripeti il test con gli altri container attivi. Un downloader, un indicizzatore di foto, un motore di backup o un processo locale di IA possono ridurre la capacità di Jellyfin anche se il carico di lavoro di Jellyfin non è cambiato.

Usa una matrice del carico di lavoro invece di un limite di utenti

Presenta la capacità come un carico di lavoro testato, ad esempio “tre flussi rappresentativi più una scansione pianificata restano entro l'obiettivo”, non come “questo server supporta dieci utenti”. Il risultato può essere riprodotto quando cambiano la libreria, i client e l'utilizzo domestico.