Ile równoczesnych zadań Plex może obsłużyć, zanim jakość odtwarzania bezpośredniego się pogorszy?

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Plex nie ma uniwersalnego limitu jednoczesnych zadań; tryb Direct Play pogarsza się dopiero wtedy, gdy nakładające się zadania zużywają margines zasobów nadal potrzebny do dostarczania multimediów.

Skanowanie biblioteki, tworzenie kopii zapasowej, indeksowanie zdjęć, klient pobierania, maszyna wirtualna lub transkodowanie mogą działać równolegle z Plexem, ale nie obciążają zasobów w takim samym stopniu. Dlatego użyteczny próg nie jest liczbą zadań. To pierwszy powtarzalny moment, w którym znana sesja Direct Play traci margines potrzebny do uruchamiania, przewijania lub płynnego buforowania podczas działania konkurencyjnego obciążenia.

Definiuj jednoczesne obciążenie na podstawie zapotrzebowania na zasoby, a nie liczby zadań

Na początku rozdziel jednoczesne zadania według faktycznie zużywanych zasobów. Skanowanie metadanych może powodować odczyty małych plików i obciążenie bazy danych, kopia zapasowa może zdominować sekwencyjne operacje wejścia-wyjścia, a transkodowanie wideo może stale obciążać procesor lub akcelerator. Nazywanie wszystkich trzech „jednym zadaniem” ukrywa część serwera, o którą konkurują.

Praktyczna granica pojawia się wtedy, gdy zapotrzebowanie dociera do współdzielonego zasobu, a nie wtedy, gdy istnieje określona liczba procesów. Czas procesora, dostępna pamięć, operacje wejścia-wyjścia pamięci masowej i przepustowość sieci mają odrębną pojemność, dlatego limity zasobów wymagają osobnych sygnałów, zamiast jednego ogólnego wskaźnika wykorzystania.

Opisz obciążenie jako zestaw: jedna sesja Direct Play, jedna kopia zapasowa, jedno skanowanie, dwa kontenery i tak dalej. Taki opis można później odtworzyć, a test pozostaje powiązany z rzeczywistym użytkowaniem domowym, zamiast z arbitralną liczbą procesów działających w tle.

Utrzymuj stałe warunki Direct Play przed pomiarem zapasu zasobów

Wybierz jeden plik i klienta, które już niezawodnie działają w trybie Direct Play, a następnie pozostaw bez zmian wybraną ścieżkę dźwiękową, napisy, jakość i trasę sieciową. Jeśli sesja niepostrzeżenie przełączy się na transkodowanie, test dotyczy już innego zadania i nie pozwoli określić, jak duże obciążenie równoległe toleruje ścieżka Direct Play.

Direct Play zależy od zgodności klienta i możliwości dostarczania danych, a nie tylko od procesora serwera. Stabilny punkt odniesienia powinien zatem potwierdzać, że oryginalny plik pozostaje zgodny, a sieć ma wystarczający zapas dla jego rzeczywistej przepływności, zanim zostanie dodane jakiekolwiek konkurencyjne zadanie.

Zapisz czas uruchamiania, reprezentatywne przewijanie, ciągłość odtwarzania, wykorzystanie procesora i pamięci serwera, opóźnienia pamięci masowej oraz przepustowość sieci. Te wartości bazowe zapewnią punkt odniesienia dla późniejszego spowolnienia, zamiast opierania się na nieprecyzyjnym wrażeniu, że Plex „działał gorzej”.

Dodawaj zadania w tle po jednej warstwie

Wprowadź rzeczywiste zadania, które mogą nakładać się na oglądanie, ale przed testowaniem kombinacji dodawaj je pojedynczo. Zacznij od najczęstszego nakładania się zadań, na przykład zaplanowanej operacji na bibliotece lub kopii zapasowej, a następnie ponów to samo żądanie odtwarzania. Jeśli sesja nadal przechodzi test, dodaj kolejne realistyczne zadanie, zamiast od razu przechodzić do syntetycznego maksimum.

Strumień Direct Play jest zwykle lżejszy niż transkodowanie, ale nadal wymaga dostarczania danych z pamięci masowej i przez sieć. Materiał 4K o wysokiej przepływności pokazuje, dlaczego Direct Play nadal zużywa rzeczywiste zasoby, nawet gdy serwer nie koduje ponownie wideo, dlatego rywalizacja o pamięć masową lub sieć może pogorszyć odtwarzanie bez wąskiego gardła obliczeniowego.

Pozostaw każde dodane zadanie wystarczająco długo, aby osiągnęło normalny stan ustalony. Kopia zapasowa działająca przez dziesięć sekund lub skanowanie, które już się zakończyło, nie ujawni takiej samej rywalizacji jak obciążenie faktycznie nakładające się na wieczorny czas oglądania.

-15% OFF

Obserwuj pierwszy współdzielony zasób, który traci zapas

Potraktuj pierwszą zmianę widoczną dla użytkownika jako znacznik czasu, a następnie porównaj sygnały dotyczące zasobów z tego przedziału. Skok wykorzystania procesora ma znaczenie tylko wtedy, gdy praca obliczeniowa również zaczyna się opóźniać; wysokie wykorzystanie pamięci ma znaczenie, gdy odzyskiwanie pamięci lub użycie pamięci wymiany zmienia opóźnienia; w przypadku pamięci masowej i sieci potrzebne są dane o kolejce, opóźnieniu lub przepustowości, a nie tylko wykres wyglądający na aktywny.

Kluczowym pojęciem jest rywalizacja o współdzielony zasób. Gdy kilka zadań jednocześnie potrzebuje tego samego procesora, pamięci, dysku lub połączenia sieciowego, czas odpowiedzi może wzrosnąć, nawet jeśli pozostałe części serwera nadal wydają się nieobciążone.

Wstrzymaj podejrzane konkurencyjne zadanie i ponów to samo żądanie Direct Play. Jeśli odtwarzanie natychmiast wróci do wartości bazowych, a odpowiadający mu sygnał obciążenia spadnie, granica współbieżności zaczyna być potwierdzona. Jeśli nic się nie zmieni, przywróć obciążenie i przetestuj kolejny współdzielony zasób, zamiast zgadywać na podstawie potrzeby modernizacji sprzętu.

Zamień zaobserwowany punkt awarii w granicę przepustowości

Użyteczne określenie przepustowości wskazuje obciążenie i zasób, który zawiódł: na przykład jedna znana sesja Direct Play pozostaje stabilna przy normalnie działających kontenerach i skanowaniu, ale opóźnienia pamięci masowej rosną, a przewijanie przestaje działać po uruchomieniu kopii zapasowej. Taki opis można łatwiej odnieść do własnego serwera niż stwierdzenie „Plex obsługuje sześć zadań”.

Bardzo duże wdrożenia Plex pokazują, dlaczego ogólna liczba sesji nie jest uniwersalną granicą. W konfiguracji obsługującej 40–50 jednoczesnych sesji mogą występować strumienie bezpośrednie, transkodowanie, określona przepustowość sieci i wybór sprzętu całkowicie różne od tych w małym serwerze domowym.

Utrzymuj margines bezpieczeństwa poniżej pierwszej powtarzalnej awarii i ponawiaj test po większych zmianach obciążenia. Jeśli pytanie dotyczy konkretnie mieszanych klientów, którzy powinni pozostać w trybie Direct Play, użyj granicy Direct Play dla mieszanych klientów, aby oddzielić zmiany zgodności od nasycenia współdzielonych zasobów.

Centrum Technologii i Sztucznej Inteligencji

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.