Ilu użytkowników może obsłużyć Jellyfin na małym serwerze domowym?

Nie ma uczciwej, stałej liczby użytkowników małego serwera Jellyfin, ponieważ znacznie większe znaczenie mają równoczesne ścieżki odtwarzania i przepływności niż liczba zarejestrowanych kont.

Dziesięć profili rodzinnych, które rzadko korzystają z serwera jednocześnie, może być łatwiejsze do obsłużenia niż dwóch jednoczesnych użytkowników, których klienci wymuszają mapowanie tonów 4K, wypalanie napisów i konwersję przepływności na potrzeby zdalnego odtwarzania. Pojemność należy więc przewidywać na podstawie równoczesnych jednostek obciążenia: sesji Direct Play, remuksowania, konwersji dźwięku, transkodowania wideo, zadań w tle oraz zapotrzebowania na zdalne pasmo. Najmniejszy zapas zasobów spośród tych kategorii wyznacza praktyczny limit użytkowników.

Zarejestrowani użytkownicy to nie to samo co równoczesne obciążenie

Konto Jellyfin podczas bezczynności zużywa niemal niezauważalną część dostępnej wydajności odtwarzania. Obciążenie serwera pojawia się, gdy użytkownicy przeglądają bibliotekę, przesyłają strumieniowo, transkodują, skanują zawartość lub aktualizują metadane, a działania te nakładają się w czasie. Planowanie na podstawie łącznej liczby kont domowych myli więc zarządzanie tożsamością z równoczesnością. Przydatną wartością jest liczba jednoczesnych kosztownych operacji w najbardziej obciążonym typowym okresie.

Przewodnik ZimaSpace dotyczący przepustowości modeluje zapotrzebowanie zdalne na podstawie przepływności strumieni dostarczanych jednocześnie, a nie liczby kont. Ten model równoczesnych strumieni można uogólnić na cały serwer: należy policzyć aktywne obciążenia i ścieżki zasobów, których wymagają, a następnie dodać zapas na skoki obciążenia, zamiast dzielić wynik testu procesora przez szacowaną liczbę osób.

Granica zależy od zmienności zachowań. Gospodarstwo domowe może mieć przewidywalne wieczorne nakładanie się aktywności, natomiast współdzielony dostęp wielu użytkowników zdalnych może powodować bardziej gwałtowne skoki równoczesnego obciążenia. Jeśli to możliwe, używaj zaobserwowanej maksymalnej liczby sesji, a jeśli nie — zachowawczo zaplanowanego maksimum. Nie licz każdego zarejestrowanego konta jako jednoczesnego użytkownika, chyba że rzeczywiście tego wymaga usługa.

Użytkowników korzystających z Direct Play zwykle najpierw ograniczają pamięć masowa i sieć

Gdy urządzenia klienckie obsługują źródłowe pliki multimedialne, każda sesja Direct Play staje się w dużej mierze obciążeniem odczytu i sieci. Użycie procesora może pozostać niewielkie, dlatego mały serwer może obsłużyć kilka takich sesji, dopóki łączna przepływność multimediów, równoczesność operacji dyskowych lub przepustowość sieci nie stracą odpowiedniego zapasu. Dokładna liczba zależy od tego, czy pliki są w rozdzielczości 1080p, czy są to pliki 4K o wysokiej przepływności, a także od tego, czy treści są dostarczane lokalnie, czy zdalnie.

Wskazówki sprzętowe Jellyfin podkreślają, że pamięć masowa multimediów potrzebuje przy zwykłym odtwarzaniu jedynie prędkości sekwencyjnej wyższej od wymaganej przepływności, natomiast sieć musi przenosić dostarczane strumienie. Ścieżka zasobów Direct Play wyjaśnia, dlaczego energooszczędna maszyna może obsłużyć więcej kompatybilnych użytkowników, niż sugerowałaby klasa jej procesora, pod warunkiem że pamięć masowa i sieć pozostają wyraźnie poniżej nasycenia.

Granica zależy od maksymalnej przepływności, a nie od średniego rozmiaru pliku. Multimedia o zmiennej przepływności mogą chwilowo przekraczać średnią, a kilka niezależnych strumieni może jednocześnie wykonywać operacje przewijania. Zachowaj zapas zamiast wykorzystywać łącze lub dysk do teoretycznego maksimum, a następnie sprawdź działanie na rzeczywistych plikach o najwyższej przepływności, które gospodarstwo domowe zamierza odtwarzać jednocześnie.

Użytkownicy korzystający z transkodowania zużywają inną pulę zasobów

Transkodowanie wideo dodaje dekodowanie, filtrowanie, mapowanie tonów lub komponowanie napisów, kodowanie oraz wejścia i wyjścia tymczasowych segmentów. Akceleracja sprzętowa może zwiększyć wydajność, ale o liczbie strumieni pozostających powyżej czasu rzeczywistego decydują obsługiwane kodeki, generacja silnika, dostęp sterownika, ustawienia wyjściowe i równoczesne wykorzystanie silnika. Jedno programowe rozwiązanie awaryjne może zużyć więcej procesora niż kilku użytkowników Direct Play łącznie.

Wskazówki dotyczące transkodowania sprzętowego wyraźnie pokazują tę różnicę: konwersja wideo wyłącznie za pomocą procesora może być niezwykle wymagająca, podczas gdy odpowiednie silniki multimedialne znacznie wydajniej obsługują wspierane ścieżki. Dlatego „liczbę użytkowników” małego serwera należy podzielić na tanie sesje Direct Play i kosztowne sesje konwersji, zamiast uśredniać je do jednej liczby.

Granica jest wyznaczana przez utrzymywaną prędkość transkodowania i narastanie kolejki. Kolejnego użytkownika transkodującego należy doliczyć tylko wtedy, gdy każdy reprezentatywny strumień pozostaje powyżej czasu rzeczywistego po kilku minutach i przy normalnym stanie termicznym. Jeśli jedna ze ścieżek przełącza się na tryb programowy lub spada poniżej czasu rzeczywistego, jej udział w wydajności trzeba przeliczyć osobno, zamiast ukrywać go w średniej.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Usługi działające w tle i stan pamięci podręcznej zmieniają tę samą liczbę użytkowników

Skanowanie bibliotek, kopie zapasowe, programy pobierające, indeksowanie zdjęć i inne kontenery mogą zmniejszyć zapas dostępny dla tej samej liczby widzów. Pusta pamięć podręczna sprawia również, że początkowe przeglądanie i obsługa metadanych są bardziej wymagające niż przy powtarzających się żądaniach z rozgrzaną pamięcią podręczną. Test wydajności wykonany na bezczynnym serwerze z rozgrzaną pamięcią może więc zawyżyć ocenę tego, czego gospodarstwo domowe doświadczy podczas rzeczywistego wieczornego szczytu.

Analiza stosu usług ZimaSpace wskazuje, że kontenery zachowują odrębne granice cyklu życia, ale nadal współdzielą procesor, pamięć RAM, pamięć masową i akceleratory hosta. Model współdzielonych zasobów pokazuje, dlaczego usługi sąsiednie powinny należeć do realistycznego testu wydajności: mogą przenieść pierwsze wąskie gardło z sieci lub transkodowania na kolejkę pamięci masowej albo presję na pamięć, nie dodając kolejnego użytkownika Jellyfin.

Granica zależy od wymogu współistnienia. Jeśli kopię zapasową można bezpiecznie zaplanować poza godzinami oglądania, nie powinna ona wymuszać większego hosta Jellyfin. Jeśli indeksowanie zdjęć lub inna usługa musi działać stale w tym samym czasie i wielokrotnie powoduje nasycenie tego samego zasobu, jej zapotrzebowanie należy uwzględnić w zakresie wydajności, ponieważ usunięcie go zmieniłoby rzeczywiste wymagania domowego serwera.

Przekształć gospodarstwo domowe w jednostki obciążenia i dodawaj użytkowników, aż zabraknie zapasu

Utwórz jedną jednostkę obciążenia na podstawie rzeczywistego szczytowego zestawu, na przykład dwóch lokalnych sesji Direct Play, jednego zdalnego transkodowania i usługi działającej w tle, która zwykle działa jednocześnie. Zmierz czas do pojawienia się pierwszej klatki, buforowanie, prędkość transkodowania, nasycenie procesora lub układu GPU, presję na pamięć, opóźnienia pamięci masowej i przepustowość sieci. Dodawaj po jednej reprezentatywnej sesji, zachowując stałe multimedia i klientów, aby można było przypisać pierwszą awarię konkretnemu zasobowi.

Metoda nasycenia zasobów dostarcza reguły decyzyjnej: należy szukać wykorzystania, nasycenia i błędów w każdym zasobie, zamiast wybierać jeden główny wskaźnik. Gdy jedna kolejka wielokrotnie pojawia się, zanim odtwarzanie nie zdąży zrealizować swojego terminu, to ona wyznacza limit równoczesności bieżącej konfiguracji; kolejny wynik procesora nie zmienia zaobserwowanego wąskiego gardła.

Publikuj wydajność jako opis obciążenia, a nie uniwersalną liczbę użytkowników: „ten serwer obsługuje ten zestaw klientów i multimediów z takim zapasem”. Utrzymuj środowisko produkcyjne o jeden krok poniżej pierwszej powtarzalnej awarii i ponownie przeprowadzaj testy po zmianie kodeków, klientów, pamięci masowej, sieci lub usług działających w tle. Taka odpowiedź pozostaje użyteczna nawet przy zmianie liczby zarejestrowanych użytkowników, ponieważ jest powiązana z rzeczywistym równoczesnym zapotrzebowaniem.