Quanti utenti simultanei può gestire Plex prima di rallentare?
Non esiste un limite universale utile per gli utenti Plex; la concorrenza stabile è la combinazione più ampia di sessioni reali che può essere gestita prima che lo spazio di archiviazione, la rete o la transcodifica perdano margine.
Dieci utenti in Direct Play possono essere meno impegnativi di due transcodifiche remote esigenti, e un server che sembra avere ampio margine durante la riproduzione continua può bloccarsi quando diversi spettatori iniziano la visione o cercano contemporaneamente. Tieni conto delle modalità di riproduzione effettive, dei bitrate, dei percorsi dei sottotitoli e dell’HDR e dell’utilizzo dell’upload remoto. Quindi aggiungi sessioni rappresentative una alla volta e fermati al primo collo di bottiglia riproducibile, invece di stimare la capacità in base al modello della CPU o al numero di account.
Conta i percorsi di riproduzione, non gli account
Il numero di persone che hanno accesso a Plex non corrisponde al numero di carichi di lavoro simultanei. Inizia osservando il periodo reale di maggiore attività e classifica ogni sessione attiva come Direct Play, Direct Stream, conversione del solo audio o transcodifica video. Queste modalità consumano risorse del server molto diverse.
Dieci o più sessioni simultanee possono comunque produrre limiti molto diversi a seconda del numero di percorsi Direct Play, remux, conversione audio e transcodifica video attivi. Un semplice conteggio degli utenti non può prevedere il punto in cui inizierà il rallentamento.
Costruisci un set di test basato sulla sovrapposizione massima plausibile, non sull’elenco totale di persone della famiglia o degli amici. Se sei utenti si sovrappongono raramente e usano tutti Direct Play, il problema di capacità è diverso rispetto a tre transcodifiche 4K simultanee.
Individua la prima risorsa condivisa a perdere margine
Le sessioni simultanee condividono lo spazio di archiviazione dei contenuti multimediali, l’interfaccia di rete del server, il lavoro della CPU per audio e sottotitoli, lo spazio temporaneo per la transcodifica e qualsiasi motore video hardware utilizzato per la conversione. Il limite è determinato dalla risorsa necessaria che cede per prima durante l’utilizzo reale, non dal componente con il valore nominale più elevato.
I carichi Plex ad alta concorrenza possono evidenziare più colli di bottiglia tra unità, rete, transcodifica e percorsi dati interni. Usa la stessa visione multi-risorsa anche su scala ridotta per un home server.
Registra la latenza dei dischi multimediali, il throughput di rete, l’utilizzo di CPU e motori video della GPU, la pressione sulla memoria e la velocità di transcodifica mentre aggiungi sessioni una alla volta. Il primo parametro che perde costantemente margine nello stesso momento in cui peggiora la qualità della riproduzione indica il limite di capacità utile.
Gli utenti remoti aggiungono un limite separato per l’upload
Gli stream locali possono rimanere interamente all’interno di una LAN veloce, mentre ogni stream remoto condivide l’upload della connessione domestica. Anche un server potente può rallentare dal punto di vista dell’utente quando la combinazione dei bitrate originali o transcodificati supera la capacità di upload disponibile dopo il resto del traffico domestico.
La capacità remota deve considerare la capacità di rete e di transcodifica come limiti separati. Una GPU più veloce non può fare in modo che un collegamento WAN sovraccarico trasferisca più dati.
Testa la concorrenza remota dall’esterno della rete domestica, non aprendo diverse schede del browser in locale. Se il primo limite è l’upload, riduci i bitrate remoti o migliora la connessione prima di acquistare una CPU più potente. Se l’upload rimane entro livelli confortevoli e la velocità di transcodifica diminuisce, il percorso di elaborazione è il limite più probabile.
Avvii e ricerche mettono in evidenza il margine dei picchi
La riproduzione a regime è spesso più semplice da gestire rispetto all’avvio o alla ricerca simultanea da parte di più utenti. Questi momenti generano letture a raffica, nuovi buffer, richieste di metadati e nuovi flussi di rete prima che il carico si stabilizzi.
Un numero fisso di stream non è sufficiente per la pianificazione delle transcodifiche simultanee; il test di accettazione deve includere i formati dei file, i bitrate di destinazione, i percorsi dei sottotitoli e il lavoro di conversione che può iniziare nello stesso momento.
Registra il tempo necessario per visualizzare il primo fotogramma e il recupero dopo una ricerca mentre la combinazione di sessioni prevista è già attiva. Se falliscono solo gli avvii sincronizzati, il limite potrebbe dipendere da picchi di attività dello spazio di archiviazione, dalla latenza dello stato dell’app o dalla gestione delle code, anziché dall’elaborazione sostenuta.
I processi in background possono ridurre lo stesso margine
Scansioni, backup, download e processi di analisi possono consumare la stessa capacità di archiviazione, CPU, memoria o rete necessaria agli spettatori attivi. Di conseguenza, un server che supera un benchmark in condizioni tranquille può non raggiungere il vero picco di utilizzo domestico.
Esegui una volta la combinazione di sessioni prevista con la manutenzione non essenziale sospesa e una volta con un processo in background rappresentativo attivo. La differenza mostra se sia possibile recuperare margine tramite la pianificazione, invece di acquistare hardware più potente.
Se la riproduzione continua a non funzionare con i processi in background sospesi, mantieni il limite di concorrenza nel percorso di riproduzione. Se il problema scompare, pianifica o isola il processo concorrente e conserva la configurazione di base del server, meno costosa.
Conserva nel runbook le definizioni dei carichi di lavoro che superano e non superano il test. In questo modo il limite operativo rimane riproducibile dopo una modifica a client, codec, pool di archiviazione o attività pianificata.
Imposta un limite operativo sulla base di un test ripetuto
Un limite di concorrenza utile è la combinazione di sessioni stabile e ripetibile, non il numero massimo che funziona per trenta secondi. Riproduci contenuti rappresentativi durante le scene più impegnative, esegui una ricerca e osserva il sistema abbastanza a lungo da permettere a temperature, code e velocità di transcodifica di stabilizzarsi.
Un test di carico remoto 4K dimensiona l’hardware solo dopo aver verificato le esigenze di Direct Play, upload e transcodifica, così il limite di concorrenza rimane legato al carico misurato anziché al numero di account.
Documenta la combinazione che supera il test e la prima modalità di errore. Se un ulteriore stream Direct Play satura la rete, il limite è basato sulla rete. Se un’ulteriore transcodifica scende al di sotto della riproduzione in tempo reale, il limite è basato sull’elaborazione. Ripeti il test dopo modifiche importanti a client, codec, spazio di archiviazione o rete, invece di considerare il numero permanente.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
