Jakie czynniki konfiguracyjne decydują o skalowalności Jellyfin?

Skalowalność Jellyfin jest określana przez pierwszy zasób lub zależność, która zostanie wysycona przy rzeczywistym połączeniu odtwarzania i zadań wykonywanych w tle w danym gospodarstwie domowym.

Dwa serwery z tym samym procesorem mogą obsługiwać zupełnie różne obciążenia, jeśli jeden głównie korzysta z funkcji Direct Play dla zgodnych plików, a drugi w tym samym czasie wypala napisy, wykonuje mapowanie tonów HDR, obsługuje użytkowników zdalnych i skanuje biblioteki. Konfiguracja ma znaczenie, ponieważ określa ścieżkę przetwarzania, sposób korzystania z pamięci masowej oraz zapotrzebowanie na sieć generowane przez każdą sesję, zanim istotna stanie się surowa wydajność sprzętu.

Tryb odtwarzania decyduje, który zasób stanie się kosztowny

Sesja Direct Play wymaga od serwera głównie odczytania pliku multimedialnego i dostarczenia go z odpowiednią przepływnością, więc koszt obliczeniowy może pozostać niewielki. Remuksowanie dodaje operacje na kontenerze, konwersja dźwięku dodaje obciążenie kodeka, a transkodowanie wideo może przenieść główne obciążenie na sprzętowy silnik multimedialny GPU lub procesor. Skalowalność zaczyna się więc od odsetka sesji, które pozostają na taniej ścieżce.

Wskazówki sprzętowe Jellyfin rozróżniają te ścieżki i ostrzegają, że transkodowanie wideo wyłącznie za pomocą procesora może być niezwykle wymagające, szczególnie podczas przetwarzania HDR do SDR. Wskazówki dotyczące akceleracji sprzętowej potwierdzają zasadę warunkową: „mały serwer” może dobrze skalować się dla zgodnych klientów, ale osiągnąć bardzo niski limit, gdy ci sami klienci wymuszą kosztowną konwersję programową.

Granica wynika ze zmienności klientów. Benchmark oparty na jednym łatwym pliku H.264 nie przewidzi gospodarstwa domowego zawierającego materiały 4K HEVC, napisy graficzne, nieobsługiwany dźwięk i przeglądarki o różnym poziomie obsługi dekodowania. Test skalowalności należy oprzeć na rzeczywistej macierzy multimediów i klientów, a następnie utrzymywać tę macierz bez zmian podczas zwiększania liczby jednoczesnych sesji.

Ustawienia transkodowania równoważą jakość, przepustowość i moc obliczeniową

Limity przepływności, ustawienia enkodera, mapowanie tonów, obsługa napisów i docelowe kodeki zmieniają ilość pracy wymaganą przez każdy konwertowany strumień. Niższa przepływność wyjściowa może chronić zdalne łącze wysyłające, ale zwiększa obciążenie związane z konwersją, jeśli źródło mogłoby w innym przypadku korzystać z funkcji Direct Play. Ustawienie enkodera zapewniające wyższą jakość może zużywać więcej czasu akceleratora, mimo że liczba użytkowników się nie zmieniła.

Model przepustowości ZimaSpace pokazuje, dlaczego zdalną wydajność należy obliczać na podstawie jednoczesnych dostarczanych przepływności, a nie wyłącznie rozmiaru plików. Jego model jednoczesnej przepływności ujawnia również wzajemne oddziaływanie tych czynników: limit zdalnej przepustowości może zamienić problem z siecią w obciążenie związane z transkodowaniem, dlatego skalowalności nie można szacować wyłącznie na podstawie procesora lub szybkości wysyłania danych.

Granica wynika z ukończenia przetwarzania w czasie rzeczywistym. Transkodowanie, które się rozpoczyna, nie musi być zrównoważone, jeśli jego szybkość przetwarzania spadnie poniżej szybkości odtwarzania lub jeśli kolejka segmentów będzie rosnąć. Konfigurację należy uznać za skalowalną tylko wtedy, gdy każdy reprezentatywny konwertowany strumień utrzymuje zapas ponad czasem rzeczywistym przez cały okres testu, a pozostałe wymagane sesje pozostają stabilne.

Pamięć i pamięć podręczna kształtują zapas wydajności zapytań i metadanych

Użytkownicy robią więcej niż tylko oglądają wideo: przeglądają biblioteki, wyszukują materiały, wczytują grafiki, aktualizują stan obejrzenia i wykonują zapytania o metadane. Wystarczająca ilość pamięci pozwala często używanym stronom bazy danych i systemu plików pozostać w pamięci, ograniczając powtarzające się operacje pamięci masowej. Zbyt mała ilość pamięci zwiększa odzyskiwanie pamięci lub użycie pliku wymiany, co może pogorszyć działanie interfejsu, zanim silnik multimedialny osiągnie swój limit.

Praktyczny efekt jest widoczny, gdy serwer staje się szybszy po rozgrzaniu pamięci podręcznej bez żadnej zmiany sprzętu. Zachowanie rozgrzanej pamięci podręcznej oddziela ponownie wykorzystywane metadane od nowej pracy związanej z konwersją, co jest ważne podczas interpretowania testów skalowalności: dziesięć wielokrotnych otwarć biblioteki nie jest równoważne dziesięciu zimnym klientom uzyskującym dostęp do różnych części dużego katalogu.

Granica polega na tym, że pamięć podręczna nie zwiększa przepustowości pracy wymagającej obliczeń ani danych nieznajdujących się w pamięci podręcznej. Sprawny interfejs może współistnieć z przeciążonym enkoderem, a duża ilość pamięci RAM nie naprawi wysyconej sieci. Nacisk pamięci i opóźnienia powtarzanych żądań należy śledzić jako osobne osie, zamiast sprowadzać każde spowolnienie do jednego wniosku: „serwer jest przeciążony”.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Pamięć masowa i sieć tworzą niezależne limity jednoczesności

Odczyty multimediów są zwykle duże i sekwencyjne, podczas gdy baza danych Jellyfin, metadane, miniatury, dzienniki i segmenty pamięci podręcznej transkodowania mogą generować mniejsze lub bardziej wrażliwe na zapis operacje. Jednocześnie zdalne sesje współdzielą przepustowość łącza wysyłającego. Dlatego jeden system może być ograniczony lokalnie przez kolejkowanie operacji pamięci masowej, a zdalnie przez przepustowość wysyłania, nawet przy tej samej liczbie użytkowników.

Model wykorzystania, wysycenia i błędów jest przydatny, ponieważ traktuje procesor, pamięć, pamięć masową i sieć jako osobne zasoby z odrębnymi oznakami problemów. Poszukiwanie pierwszej kolejki lub błędu, który regularnie pojawia się wraz ze wzrostem jednoczesności, dostarcza więcej informacji niż średni procent użycia procesora, który może ukrywać wysycony dysk, interfejs sieciowy lub sprzętowy enkoder.

Granica wynika z nakładania się obciążeń. Dysk, który bez problemu obsługuje trzy filmy, może mieć trudności, gdy jednocześnie trafią na niego skanowanie biblioteki, kopia zapasowa, pobieranie i zapis pamięci podręcznej transkodowania. Należy testować typowe kombinacje szczytowych obciążeń, a kolidujące zadania przenosić lub planować w innym czasie dopiero wtedy, gdy ten sam zasób wielokrotnie przechodzi od wykorzystania do kolejkowania.

Mierz krzywą skalowalności zamiast podawać jeden limit użytkowników

Zacznij od stałej jednostki obciążenia, takiej jak jedno odtwarzanie Direct Play w salonie, jedno transkodowanie w przeglądarce i jeden strumień zdalny. Dodawaj po jednej jednostce, rejestrując opóźnienie do pierwszej klatki, szybkość transkodowania, buforowanie, wykorzystanie procesora lub GPU, nacisk pamięci, kolejkowanie pamięci masowej i przepustowość sieci. Najbardziej użyteczny jest kształt degradacji oraz pierwsza metryka, która traci zapas.

Analiza stosu usług ZimaSpace ostrzega również, że logiczna izolacja nie sprawia, iż zasoby hosta stają się prywatne. Model współdzielonych zasobów hosta przypomina, aby uwzględniać w teście sąsiednie usługi, gdy zwykle działają równolegle z Jellyfin; w przeciwnym razie benchmark opisuje stan laboratoryjny, którego gospodarstwo domowe nigdy faktycznie nie używa.

Ustal skalowalny limit o jeden krok poniżej pierwszej powtarzalnej awarii, a nie na poziomie maksymalnej liczby sesji, która raz przypadkiem się uruchomiła. Powtarzaj tę samą macierz po zmianach konfiguracji i uznawaj poprawę tylko wtedy, gdy wąskie gardło się przesunie lub zapas wzrośnie bez pogorszenia innej ścieżki. W ten sposób uzyskasz możliwy do obrony zakres przepustowości zamiast marketingowej liczby użytkowników na serwer.