Ile jednoczesnych transmisji Jellyfin może obsłużyć serwer domowy, zanim jakość odtwarzania się pogorszy?

Jellyfin nie ma uniwersalnego limitu liczby strumieni; stabilna współbieżność kończy się wtedy, gdy najbardziej wymagające typowe obciążenie wielokrotnie zużywa margines bufora klienta.

Serwer domowy z sześcioma klientami korzystającymi głównie z odtwarzania bezpośredniego może być mniej obciążony niż jeden zdalny strumień HDR z wypalaniem napisów. Zmierz tryby odtwarzania, etapy konwersji oraz usługi konkurujące o zasoby w najbardziej obciążonym typowym okresie. Wynik wyznaczy praktyczny limit powiązany z Twoim obciążeniem, a nie mylącą zasadę „liczba użytkowników na procesor”.

Licz tryby odtwarzania zamiast użytkowników

Każda sesja Jellyfin korzysta z innej ścieżki: odtwarzanie bezpośrednie głównie odczytuje i przesyła plik, natomiast remultipleksowanie, konwersja dźwięku i transkodowanie wideo stopniowo zwiększają obciążenie. Liczenie sesji bez sklasyfikowania ich ścieżek ukrywa rzeczywiste dane wejściowe dla potoku multimedialnego.

Przydatna tabela obciążenia rejestruje obciążenie transkodowania dla każdego reprezentatywnego klienta i pliku źródłowego, uwzględniając kodek, stan HDR, napisy, rozdzielczość oraz zdalną przepływność.

Wynik jest miarodajny dopiero po przypisaniu każdej sesji do nazwanej klasy. Dwóch prostych strumieni odtwarzania bezpośredniego nie należy ważyć tak samo jak jednej konwersji 4K HDR z napisami graficznymi.

Najbardziej wymagająca typowa ścieżka wyznacza pierwszy limit

Współbieżność zwielokrotnia wyłącznie zasoby wykorzystywane przez daną ścieżkę. Strumień odtwarzany bezpośrednio obciąża odczyt z pamięci masowej i dostarczanie przez sieć, podczas gdy transkodowanie może zużywać zasoby dekodowania, filtrów, mapowania tonów, kodowania, pamięci tymczasowej oraz awaryjnego przetwarzania przez CPU.

Zmierz aktywnie wykorzystywany zasób za pomocą wykorzystania i wysycenia, zamiast polegać na pojedynczym procencie użycia GPU lub CPU. Kolejka może powstać, gdy jeden etap nie zapewnia obsługi w czasie rzeczywistym, nawet jeśli pozostałe komponenty nadal mają zapas mocy.

Pierwsza powtarzalna kolejka lub utrata marginesu bufora to użyteczny limit dla danego obciążenia. Niewykorzystane, szybsze zasoby w innych miejscach go nie podniosą.

Zdalne i współdzielone obciążenia zmieniają granicę

Sesje zdalne zwykle mają mniejszy budżet wysyłania i bardziej zmienne opóźnienia niż klienci lokalni. Równoległe zadanie tworzenia kopii zapasowej, indeksowania lub pobierania może również korzystać z tej samej ścieżki pamięci masowej albo sieciowej i zmniejszać zapas dokładnie w tych minutach, gdy widzowie rozpoczynają odtwarzanie lub przewijają.

Porównuj przypadki lokalne i zdalne, korzystając z modelu zasobów dla wielu aplikacji, zachowując te same multimedia i zasady klienta. Jeśli tylko przypadek zdalny traci margines bufora, granica wynika ze ścieżki lub budżetu wysyłania, a nie z silnika multimedialnego.

Ten sam serwer ma więc kilka limitów: lokalne odtwarzanie bezpośrednie, lokalne transkodowanie, dostarczanie zdalne oraz szczytowe obciążenie współdzielone z innymi usługami.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Ustal powtarzalny próg wydajności

Przydatny test akceptacyjny rozpoczyna się od najbardziej wymagającej oczekiwanej sesji, a następnie dodaje po jednym normalnym współbieżnym strumieniu. Rejestruj czas uruchamiania, stabilność bufora podczas odtwarzania, pominięte klatki, głębokość kolejki oraz zasób, który jako pierwszy osiąga wysycenie.

Jako regułę zatrzymania zastosuj testy z zimną i ciepłą pamięcią podręczną: zachowaj zapas tam, gdzie opóźnienia, błędy lub kolejkowanie stają się powtarzalne, a nie tam, gdzie panel jedynie pokazuje wysokie wykorzystanie.

Zakończ test, gdy docelowe połączenie przejdzie go kilkukrotnie przy stabilnym odtwarzaniu i widocznym zapasie. Nie przeliczaj wyniku na uniwersalną liczbę strumieni dla innych multimediów lub klientów.