Dlaczego wydajność Jellyfin różni się w sieci lokalnej i przy połączeniach zdalnych

Eva Wong

IceWhale author

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.

Why Jellyfin Performance Differs on LAN and Remote Connections

Jellyfin działa inaczej zdalnie, ponieważ ten sam serwer ma do dyspozycji mniejszy budżet wysyłania danych, większą zmienność trasy, inne routowanie i często inny profil odtwarzania.

Telewizor 4K podłączony przewodowo przez Ethernet może odtwarzać plik o wysokiej przepływności w trybie bezpośrednim, podczas gdy telefon korzystający z sieci komórkowej otrzymuje ograniczony do 1080p transkodowany strumień przez odwrotne proxy lub VPN. Sprzęt serwera się nie zmienił, ale zmieniły się klient, dostępna przepływność, opóźnienie i ścieżka zabezpieczeń. Te zmienione warunki wybierają inne zadania i tworzą inne granice awarii.

Przepustowość sieci LAN zwykle zachowuje oryginalną ścieżkę odtwarzania

Przewodowa sieć LAN zazwyczaj oferuje wysoką, stabilną przepustowość i małe opóźnienia, dzięki czemu kompatybilne urządzenia mogą żądać oryginalnych plików bez obniżania jakości. Wykrywanie urządzeń lokalnych i bezpośrednie adresowanie prywatne usuwają również kilka zależności związanych z nawiązywaniem połączenia.

Celem bezpośredniego odtwarzania jest przesłanie istniejącego materiału bez jego modyfikowania. W sieci LAN wystarczająca przepustowość sprawia, że ten tryb jest możliwy nawet dla przepływności źródłowych, które przekraczałyby możliwości wielu domowych łączy wysyłania.

Ta przewaga znika w przeciążonej sieci Wi-Fi lub w przypadku klienta, który nie potrafi dekodować źródła. „Lokalnie” opisuje topologię, a nie gwarantowaną wydajność, więc słabe połączenie bezprzewodowe nadal może stać się najwolniejszym etapem.

Zdalne wysyłanie i reguły przepływności mogą uruchomić konwersję

Zdalny ruch opuszcza lokalizację serwera przez łącze wysyłania, które często jest znacznie wolniejsze niż jego usługa pobierania lub sieć LAN. Jellyfin lub klient może wybrać niższą przepływność, wymagając konwersji wideo, nawet jeśli zdalne urządzenie obsługuje oryginalny kodek.

Model przepustowości wykorzystujący jednoczesne strumienie i prędkość wysyłania pokazuje, dlaczego każda dodatkowa sesja zdalna zużywa wspólny budżet łącza wychodzącego. Szczytowe wartości przepływności źródła wymagają zapasu wykraczającego poza prostą średnią.

Konsekwencją jest sprzężony popyt: obniżenie przepływności sieci oszczędza wysyłanie, ale zwiększa zużycie mocy obliczeniowej serwera. Lokalnie bezczynny procesor GPU może stać się zajęty dopiero po połączeniu zdalnych użytkowników.

Routowanie internetowe dodaje opóźnienia, straty i pośredników

Sesje zdalne mogą przechodzić przez routowanie operatora, NAT, terminowanie TLS, odwrotne proxy, siatkowe sieci VPN lub przekaźniki. Każdy z tych elementów może wprowadzać buforowanie, przekroczenia limitu czasu, ograniczenia nagłówków lub przepustowości, które nie występują między dwoma adresami LAN.

Doniesienia o płynnym odtwarzaniu w sieci LAN, ale buforowaniu zdalnie pokazują, że ten sam materiał i sprzęt serwera mogą zachowywać się inaczej po zmianie ścieżki sieciowej i proxy. Objaw nie wskazuje, który pośrednik jest za to odpowiedzialny.

Większe opóźnienie jest najbardziej widoczne podczas uruchamiania, przewijania i odzyskiwania po utracie pakietów. Podczas ciągłego odtwarzania odpowiednie buforowanie może ukryć opóźnienie, ale nie jest w stanie bez końca kompensować niewystarczającej przepustowości.

-15% OFF

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

Single board computer zimaboard2

Procedura porównania sieci LAN i połączenia zdalnego

Porównanie traci wiarygodność, jeśli między testami zmieni się klient, żądana jakość, ścieżka napisów lub tryb odtwarzania. Wyniki zdalne i lokalne muszą zachowywać te zmienne bez zmian, zanim zostaną wyciągnięte wnioski dotyczące sieci.

Wykorzystaj ścieżkę odtwarzania od końca do końca, aby osobno oznaczyć magazynowanie, konwersję i dostarczanie. Następnie sprawdź tryb odtwarzania w panelu wraz z pomiarami systemu operacyjnego i sieci. Osobny raport terenowy również potwierdza zasadność użycia porównania LAN z połączeniem zdalnym zamiast zakładania, że widoczny objaw wskazuje wąskie gardło.

Przetestuj to samo urządzenie i plik lokalnie, zdalnie w oryginalnej jakości oraz zdalnie przy stałej, niższej przepływności. Zapisz tryb odtwarzania, prędkość transkodowania, wysyłanie, opóźnienie, straty pakietów, czas uruchamiania i liczbę zdarzeń ponownego buforowania; pierwsza zmienna, która zmienia się wraz z wystąpieniem problemu, wskazuje kolejną warstwę do zbadania.