Planowanie zasobów Plex: dlaczego współbieżność różnych klientów zmienia płynność bezpośredniego odtwarzania

Współbieżność różnych klientów wpływa na płynność odtwarzania Plex Direct Play, gdy nakładające się sesje korzystają ze współdzielonej pamięci masowej, sieci, buforów oraz zasobów transkodowania, które mogą zostać przez nie uruchomione.

Telewizor może odtwarzać bezpośrednio plik o wysokiej przepływności, podczas gdy przeglądarka wykonuje remuksowanie, a zdalny telefon transkoduje materiał do niższej przepływności. Każda z tych ścieżek stawia inne wymagania temu samemu serwerowi, a ich uruchamianie, przewijanie i zadania w tle mogą się nakładać, nawet gdy średnie wykorzystanie zasobów wygląda na niskie. Przydatny model planowania polega na śledzeniu ścieżki każdej sesji, a następnie znalezieniu pierwszego współdzielonego zasobu, który traci zapas wydajności.

Decyzje dotyczące Direct Play nadal są podejmowane dla każdego klienta osobno, nawet przy współbieżności

Współbieżność różnych klientów nie tworzy jednego trybu odtwarzania dla całego serwera. Każdy telewizor, przeglądarka, telefon lub urządzenie strumieniujące wybiera ścieżkę na podstawie obsługiwanych kodeków, wybranych ścieżek, ustawień jakości oraz warunków sieciowych. Jedna sesja może nadal korzystać z Direct Play, podczas gdy inna rozpoczyna transkodowanie z tej samej biblioteki.

Właśnie dlatego ustawienia Direct Play klienta mają znaczenie jeszcze przed analizą zbiorczych metryk serwera. Niższe ustawienie jakości zdalnej lub słabsze połączenie kodeków na jednym urządzeniu może wprowadzić obciążenie związane z konwersją, którego inny klient nigdy nie generuje.

Rozpocznij test mieszany od zapisania trybu każdej aktywnej sesji, zamiast samej całkowitej liczby widzów. Jeśli trzech klientów korzysta z Direct Play, a jeden transkoduje, planowanie zasobów jest asymetryczne od samego początku. Późniejsze spowolnienie musi być powiązane ze współdzielonym zasobem, którego obciążenie zmienia się po pojawieniu się czwartej ścieżki.

Direct Play nadal planuje obciążenie pamięci masowej i sieci

Direct Play eliminuje konieczność ponownego kodowania obrazu, ale serwer nadal otwiera pliki źródłowe, odczytuje różne przepływności, obsługuje metadane i wysyła jednoczesne strumienie sieciowe. Różni klienci mogą więc konkurować o kolejki pamięci masowej lub przepustowość łącza, podczas gdy wykresy CPU i GPU pozostają spokojne. Płynne odtwarzanie jest problemem planowania dostarczania danych, nawet gdy obciążenie obliczeniowe jest minimalne.

Administratorzy opisują rzeczywiste okresy mieszane z wieloma jednoczesnymi sesjami, a jednoczesne sesje Plex pokazują, dlaczego sama liczba strumieni niewiele mówi bez informacji o trybach odtwarzania i przepływnościach. Wniosek, który można zastosować szerzej, jest taki, że należy mierzyć współdzieloną ścieżkę faktycznie używaną przez wszystkie sesje.

Zsumuj reprezentatywne szczytowe przepływności i jednocześnie obserwuj opóźnienia pamięci masowej. Jeśli sieć zbliża się do nasycenia, a dyski nadal reagują sprawnie, presja związana z planowaniem występuje na krawędzi sieci. Jeśli wykorzystanie łącza pozostaje umiarkowane, ale operacje przewijania i odczytu trafiają do kolejki, silniejszym kandydatem jest pula multimediów.

Jedno transkodowanie może zmienić strukturę obciążenia zasobów

Niekompatybilny klient dodaje obciążenie związane z dekoderem, transformacją, enkoderem, buforami i transkodowaniem do zadania, które w przeciwnym razie mogłoby obejmować wyłącznie odczyt źródła i dostarczanie danych przez sieć. Ta jedna ścieżka może również zwiększyć presję na CPU, pamięć, pamięć tymczasową lub GPU, przez co pozostałe sesje Direct Play mogą działać gorzej, mimo że ich własny tryb się nie zmienia.

Rozróżnienie między Direct Play a transkodowaniem wyjaśnia, dlaczego współbieżność mieszana może nagle zmienić zachowanie systemu: kosztowna sesja zużywa zasoby, z których lekkie sesje wcześniej nie korzystały. Dlatego planowanie należy obserwować według klas zasobów, a nie wyłącznie na podstawie liczby widzów.

Powtórz ten sam zestaw testów dwukrotnie: raz bez klienta transkodującego i raz z nim. Pogorszenie, które pojawia się tylko w drugim uruchomieniu, wyznacza wyraźną granicę porównania. Następnie ustal, czy jako pierwszy zmienił się poziom obciążenia silnika wideo, CPU, pamięci roboczej transkodowania czy przepływności sieci.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Uruchamianie i przewijanie powodują krótkotrwałe skoki obciążenia zasobów

Stałe odtwarzanie może ukrywać najtrudniejszy moment planowania. Kilku klientów uruchamiających odtwarzanie, przewijających materiał lub zmieniających jakość w krótkim odstępie czasu powoduje nakładanie się skokowych odczytów, nowych zapełnień bufora, świeżych potoków transkodowania i żądań metadanych. Serwer z komfortowym wykorzystaniem zasobów w stanie ustalonym nadal może generować widoczne opóźnienia podczas tych zsynchronizowanych przejść.

Duże mieszane obciążenia ujawniają jednocześnie wiele wąskich gardeł, co pokazuje dyskusja o konfiguracji obsługującej dużą współbieżność, obejmująca ograniczenia pamięci masowej, sieci i transkodowania. Płynny wykres średniego obciążenia nie dowodzi, że system ma wystarczający zapas wydajności na jednoczesne uruchamianie sesji.

Rejestruj osobno czas do wyświetlenia pierwszej klatki i czas odzyskiwania płynności po przewinięciu, niezależnie od stabilnego odtwarzania. Jeśli tylko skoki obciążenia są słabym punktem, zwiększenie długotrwałej mocy obliczeniowej może nie pomóc. Bardziej ukierunkowanym rozwiązaniem może być rozłożenie w czasie zadań w tle, szybsza pamięć na dane stanu aplikacji lub większy zapas przepustowości sieci, zamiast wymiany całego serwera.

Stabilne ograniczenie wyznacza pierwszy współdzielony zasób, który traci margines

Planowanie zasobów staje się użyteczne, gdy jeden mierzony zasób wielokrotnie osiąga granicę dokładnie w momencie pogorszenia płynności Direct Play. Granicą może być łączna przepustowość sieci, opóźnienie pamięci masowej, obciążenie CPU związane z dźwiękiem lub napisami albo presja na akcelerator wywołana przez jedną konwertowaną sesję. Żadna pojedyncza metryka Plex nie reprezentuje wszystkich tych czynników.

Direct Play realizowane przez zdalne lub oparte na pamięci masowej ścieżki może być wrażliwe na buforowanie i opóźnienia, a wrażliwość Direct Play na opóźnienia pokazuje, dlaczego strumień może zawodzić bez żadnego wąskiego gardła enkodera. Obserwuj bufor klienta razem z licznikami po stronie serwera.

Jako obciążenie akceptacyjne wykorzystaj rzeczywistą mieszankę urządzeń w gospodarstwie domowym, a następnie zmieniaj jednocześnie tylko jednego klienta lub jeden współdzielony zasób. Jeśli ograniczeniem stanie się sieć, kolejnym krokiem jest test współbieżności sieci; w przeciwnym razie kontynuuj diagnozę na poziomie zasobu, który faktycznie utracił margines.