Hur många samtidiga användare klarar Plex innan det börjar gå långsamt?
Det finns ingen användbar universell Plex-gräns för antal användare; din stabila samtidighet är den största verkliga sessionsmix som klarar sig innan lagring, nätverk eller omkodning förlorar marginal.
Tio användare med Direct Play kan belasta mindre än två krävande fjärromkodningar, och en server som verkar ha gott om marginal under jämn uppspelning kan börja hacka när flera tittare startar eller söker samtidigt. Räkna med faktiska uppspelningslägen, bithastigheter, undertext- och HDR-vägar samt användning av fjärruppladdning. Lägg sedan till representativa sessioner en i taget och sluta vid den första återkommande flaskhalsen i stället för att uppskatta kapaciteten utifrån processormodell eller antal konton.
Räkna uppspelningsvägar, inte konton
Antalet personer som har åtkomst till Plex är inte samma sak som antalet samtidiga arbetsbelastningar. Börja med att observera den mest belastade verkliga perioden och klassificera varje aktiv session som Direct Play, Direct Stream, konvertering av enbart ljud eller videoomkodning. Dessa lägen förbrukar mycket olika serverresurser.
Tio eller fler samtidiga sessioner kan fortfarande ge mycket olika gränser beroende på hur många Direct Play-, remux-, ljudkonverterings- och videoomkodningsvägar som är aktiva. Ett enkelt användarantal kan inte förutsäga när avmattningen börjar.
Skapa en testuppsättning utifrån den största trovärdiga överlappningen, inte det totala hushållet eller vänlistan. Om sex användare sällan överlappar och alla använder Direct Play är det ett annat kapacitetsproblem än tre samtidiga 4K-omkodningar.
Hitta den första gemensamma resursen som förlorar marginal
Samtidiga sessioner delar medielagring, serverns nätverksgränssnitt, processorarbete för ljud och undertexter, tillfälligt omkodningsutrymme och eventuell hårdvarubaserad videoenhet som används för konvertering. Gränsen avgörs av den resurs som behövs och går sönder först under den faktiska mixen, inte av komponenten med det högsta specifikationsvärdet.
Plex-arbetsbelastningar med hög samtidighet kan blottlägga flera flaskhalsar i diskar, nätverk, omkodning och interna dataflöden. Använd samma perspektiv på flera resurser även i mindre hemserversystem.
Logga fördröjning i mediedisken, nätverkets genomströmning, processoranvändning, grafikprocessorns videoenheter, minnesbelastning och omkodningshastighet medan du lägger till sessioner en i taget. Det första måttet som konsekvent förlorar marginal vid samma punkt som uppspelningskvaliteten försämras är den användbara kapacitetsgränsen.
Fjärranvändare lägger till uppladdning som en separat gräns
Lokala strömmar kan hållas helt inom ett snabbt LAN, medan varje fjärrström delar på hemmets internetuppladdning. Även en kraftfull server kan upplevas som långsam när de sammanlagda ursprungliga eller omkodade bithastigheterna överstiger den uppströmskapacitet som återstår efter annan trafik i hushållet.
Fjärrkapacitet måste behandla nätverks- och omkodningskapacitet som separata tak. En snabbare grafikprocessor kan inte få en överbelastad WAN-upplänk att leverera mer data.
Testa samtidighet för fjärranvändare utanför hemmet, inte genom att öppna flera lokala webbläsarflikar. Om uppladdningen är det första taket bör du sänka fjärrbithastigheterna eller förbättra anslutningen innan du köper en kraftfullare processor. Om uppladdningen fortfarande har gott om marginal medan omkodningshastigheten sjunker är beräkningsvägen den tydligare begränsningen.
Starter och sökningar avslöjar burstmarginal
Uppspelning i stabilt läge är ofta enklare än när flera användare startar eller söker samtidigt. Dessa ögonblick skapar burstläsningar, nya buffertar, metadataförfrågningar och nya nätverksflöden innan arbetsbelastningen stabiliseras.
Ett fast antal strömmar räcker inte för planering av samtidiga omkodningar; godkännandetestet måste omfatta de filformat, målbithastigheter, undertextvägar och konverteringsarbeten som kan starta samtidigt.
Registrera tiden till första bildruta och återhämtningen efter en sökning medan den avsedda sessionsmixen redan är aktiv. Om endast synkroniserade starter misslyckas kan gränsen bero på burstbelastning på lagringen, fördröjning i appens tillstånd eller köbildning snarare än på uthållig beräkningskapacitet.
Bakgrundsjobb kan minska samma marginal
Sökningar, säkerhetskopieringar, nedladdningar och analysjobb kan förbruka samma lagrings-, processor-, minnes- eller nätverkskapacitet som aktiva tittare behöver. En server som klarar ett test i lugn miljö kan därför misslyckas under hushållets verkliga toppbelastning.
Kör den avsedda sessionsmixen en gång med icke nödvändigt underhåll pausat och en gång med ett representativt bakgrundsjobb aktivt. Skillnaden visar om schemaläggning, snarare än kraftfullare hårdvara, kan återställa marginalen.
Om uppspelningen fortfarande misslyckas när bakgrundsarbetet är pausat ska du behålla samtidighetsgränsen i uppspelningsvägen. Om felet försvinner bör du schemalägga eller isolera det konkurrerande jobbet och behålla den billigare serverbaslinjen.
Håll definitionerna av den arbetsbelastning som klarar respektive misslyckas samlade i driftinstruktionen. Då blir den operativa gränsen reproducerbar efter ändringar av klient, codec, lagringspool eller schemalagd uppgift.
Fastställ en operativ gräns utifrån ett upprepat test
En användbar samtidighetsgräns är den upprepade stabila sessionsmixen, inte det högsta antalet som fungerar i trettio sekunder. Kör representativt innehåll genom krävande scener, gör en sökning och övervaka systemet tillräckligt länge för att temperaturer, köer och omkodningshastighet ska hinna stabiliseras.
Ett test av en fjärrarbetsbelastning i 4K dimensionerar hårdvaran först efter att Direct Play, uppladdning och omkodningsbehov är kända, så att samtidighetsgränsen förblir kopplad till uppmätt arbete i stället för antal konton.
Dokumentera den sessionsmix som klarar testet och det första felläget. Om ytterligare en Direct Play-ström överbelastar nätverket är gränsen nätverksbaserad. Om ytterligare en omkodning sänker hastigheten under realtid är den beräkningsbaserad. Testa på nytt efter större ändringar av klient, codec, lagring eller nätverk i stället för att betrakta antalet som permanent.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
