Nie istnieje użyteczny uniwersalny limit użytkowników Plexa; stabilna liczba jednoczesnych sesji to największa rzeczywista kombinacja sesji, która działa bez utraty zapasu wydajności przez pamięć masową, sieć lub transkodowanie.
Dziesięciu użytkowników korzystających z funkcji Direct Play może obciążać serwer mniej niż dwa wymagające zdalne transkodowania, a serwer, który działa bez problemów podczas stabilnego odtwarzania, może zacząć się zacinać, gdy kilku widzów rozpocznie odtwarzanie lub przewinie materiał jednocześnie. Uwzględnij rzeczywiste tryby odtwarzania, przepływności, ścieżki napisów i HDR oraz wykorzystanie zdalnego wysyłania danych. Następnie dodawaj reprezentatywne sesje pojedynczo i zatrzymaj się przy pierwszym powtarzalnym wąskim gardle, zamiast szacować wydajność na podstawie modelu procesora lub liczby kont.
Uwzględniaj ścieżki odtwarzania, nie konta
Liczba osób mających dostęp do Plexa nie jest równa liczbie jednoczesnych obciążeń. Zacznij od obserwacji najbardziej obciążonego rzeczywistego okresu i sklasyfikuj każdą aktywną sesję jako Direct Play, Direct Stream, konwersję wyłącznie dźwięku lub transkodowanie wideo. Tryby te zużywają zupełnie różne zasoby serwera.
Dziesięć lub więcej jednoczesnych sesji może nadal prowadzić do bardzo różnych limitów, zależnie od liczby aktywnych ścieżek Direct Play, remuksowania, konwersji dźwięku i transkodowania wideo. Sama liczba użytkowników nie pozwala przewidzieć momentu spowolnienia.
Utwórz zestaw testowy na podstawie maksymalnego wiarygodnego nakładania się sesji, a nie całego gospodarstwa domowego lub listy znajomych. Jeśli sześciu użytkowników rzadko korzysta z serwera jednocześnie i wszyscy używają Direct Play, jest to zupełnie inny problem wydajnościowy niż trzy jednoczesne transkodowania 4K.
Znajdź pierwszy współdzielony zasób, który traci zapas wydajności
Jednoczesne sesje współdzielą pamięć masową z multimediami, interfejs sieciowy serwera, moc procesora potrzebną do obsługi dźwięku i napisów, przestrzeń roboczą transkodowania oraz sprzętowy silnik wideo używany do konwersji. Limit wyznacza zasób wymagany przez obciążenie, który jako pierwszy przestaje wystarczać, a nie komponent o najwyższej wartości specyfikacji.
Obciążenia Plexa przy dużej liczbie jednoczesnych sesji mogą ujawnić wiele wąskich gardeł dotyczących dysków, sieci, transkodowania i wewnętrznych ścieżek danych. Tak samo analizuj wiele zasobów w mniejszej skali serwera domowego.
Podczas dodawania sesji pojedynczo rejestruj opóźnienia dysku z multimediami, przepustowość sieci, użycie procesora, sprzętowe silniki wideo GPU, presję na pamięć oraz szybkość transkodowania. Pierwszy parametr, który konsekwentnie traci zapas w tym samym momencie, gdy pogarsza się jakość odtwarzania, wyznacza użyteczną granicę wydajności.
Użytkownicy zdalni wprowadzają osobny limit wysyłania danych
Strumienie lokalne mogą w całości działać w obrębie szybkiej sieci LAN, natomiast każdy strumień zdalny współdzieli domowe łącze internetowe do wysyłania danych. Nawet wydajny serwer może spowolnić z perspektywy użytkownika, gdy łączna przepływność oryginalnych lub transkodowanych materiałów przekroczy dostępną przepustowość wysyłania po uwzględnieniu pozostałego ruchu w gospodarstwie domowym.
Przy określaniu wydajności zdalnej należy traktować wydajność sieci i transkodowania jako osobne ograniczenia. Szybszy GPU nie sprawi, że przeciążone łącze WAN zacznie przesyłać więcej danych.
Testuj jednoczesne sesje zdalne spoza domu, a nie przez otwarcie kilku lokalnych kart przeglądarki. Jeśli pierwszym ograniczeniem jest wysyłanie danych, zmniejsz zdalne przepływności lub popraw połączenie, zanim kupisz wydajniejszy procesor. Jeśli wysyłanie danych nadal działa bez problemów, a spada szybkość transkodowania, silniejszym ograniczeniem jest ścieżka obliczeniowa.
Rozpoczynanie odtwarzania i przewijanie ujawniają zapas wydajności dla skokowych obciążeń
Stabilne odtwarzanie jest często łatwiejsze niż jednoczesne rozpoczęcie lub przewinięcie materiału przez kilku użytkowników. Takie momenty powodują skokowy odczyt danych, tworzenie nowych buforów, żądania metadanych i nowe przepływy sieciowe, zanim obciążenie się ustabilizuje.
Stała liczba strumieni nie wystarcza do planowania jednoczesnego transkodowania; test akceptacyjny musi obejmować formaty plików, docelowe przepływności, ścieżki napisów i obciążenie związane z konwersją, które mogą rozpocząć się w tym samym czasie.
Rejestruj czas do pojawienia się pierwszej klatki oraz odzyskiwanie po przewinięciu, gdy docelowa kombinacja sesji jest już aktywna. Jeśli zawodzą tylko zsynchronizowane rozpoczęcia odtwarzania, ograniczeniem może być skokowe obciążenie pamięci masowej, opóźnienia stanu aplikacji lub kolejkowanie, a nie stała moc obliczeniowa.
Zadania działające w tle mogą zmniejszyć ten sam zapas wydajności
Skanowanie, kopie zapasowe, pobieranie i zadania analityczne mogą zużywać te same zasoby pamięci masowej, procesora, pamięci lub sieci, których potrzebują aktywni widzowie. Serwer, który przechodzi cichy test, może więc nie poradzić sobie z rzeczywistym szczytowym obciążeniem gospodarstwa domowego.
Uruchom docelową kombinację sesji raz z wstrzymanymi nieistotnymi pracami konserwacyjnymi, a następnie ponownie z jednym reprezentatywnym zadaniem w tle. Różnica pokaże, czy zapas wydajności można odzyskać dzięki harmonogramowi, zamiast kupowania wydajniejszego sprzętu.
Jeśli odtwarzanie nadal zawodzi po wstrzymaniu zadań w tle, utrzymaj limit jednoczesnych sesji na poziomie wynikającym ze ścieżki odtwarzania. Jeśli problem znika, zaplanuj konkurujące zadanie lub odizoluj je i zachowaj tańszą konfigurację bazową serwera.
Przechowuj definicje obciążenia, które przechodzi i nie przechodzi testu, razem z instrukcją operacyjną. Dzięki temu limit operacyjny będzie można odtworzyć po zmianie klienta, kodeka, puli pamięci masowej lub zaplanowanego zadania.
Ustal limit operacyjny na podstawie powtarzalnego testu
Użyteczny limit jednoczesnych sesji to powtarzalna, stabilna kombinacja sesji, a nie najwyższa liczba, przy której odtwarzanie działa przez trzydzieści sekund. Odtwarzaj reprezentatywne materiały w wymagających scenach, wykonaj jedno przewinięcie i obserwuj system wystarczająco długo, aby ustabilizowały się temperatury, kolejki oraz szybkość transkodowania.
Test obciążenia zdalnym materiałem 4K pozwala dobrać sprzęt dopiero po określeniu wymagań Direct Play, przepustowości wysyłania i transkodowania, dzięki czemu limit jednoczesnych sesji pozostaje powiązany ze zmierzonym obciążeniem, a nie z liczbą kont.
Udokumentuj kombinację sesji, która przechodzi test, oraz pierwszy tryb awarii. Jeśli jeden dodatkowy strumień Direct Play wysyca sieć, limit jest wyznaczany przez sieć. Jeśli jedno dodatkowe transkodowanie powoduje spadek poniżej odtwarzania w czasie rzeczywistym, ograniczeniem jest moc obliczeniowa. Powtarzaj test po istotnych zmianach klienta, kodeka, pamięci masowej lub sieci, zamiast traktować tę wartość jako stałą.
Wsparcie i wskazówki
Więcej do przeczytania

Czy Plex może współdzielić kartę graficzną z innym kontenerem Dockera?
Plex i inny kontener często mogą korzystać z tego samego układu GPU, ale należy przetestować obsługę sterowników, mapowanie urządzeń, obciążenie silnika wideo, pamięć oraz...

Jak ustalić, czy błąd Plex pochodzi od klienta, czy od serwera
Odtwórz ten sam przypadek na innym kliencie, porównaj ścieżkę sesji, a następnie zbierz dowody z serwera dopiero wtedy, gdy zakres analizy wskaże, gdzie faktycznie...

Jak skonfigurować pamięć podręczną Plex i tymczasową pamięć na transkodowane pliki
Chroń trwały stan Plex, umieszczając tymczasowe pliki transkodowania na odpowiedniej pamięci lokalnej, a następnie zweryfikuj czyszczenie, ilość wolnego miejsca i zachowanie podczas ponownego uruchamiania.

