Dlaczego Immich działa szybciej w sieci LAN niż przez połączenia zdalne?

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 Does Immich Feel Faster on LAN Than on Remote Connections?

Immich zwykle działa szybciej w sieci LAN, ponieważ lokalni klienci pokonują krótszą trasę o mniejszych opóźnieniach, z mniejszą liczbą bram i bez domowego łącza internetowego jako wąskiego gardła.

Korzystanie zdalne może wiązać się z limitami wysyłania narzuconymi przez dostawcę internetu, sieciami komórkowymi lub hotelowymi, DNS-em, terminacją TLS, odwrotnym serwerem proxy, VPN-em albo nakładką sieciową, a czasem także z przekaźnikiem. Te elementy nie spowalniają każdego żądania w taki sam sposób: miniatury, zapytania o metadane, pobieranie oryginałów, wysyłanie plików i operacje wyszukiwania obciążają różne części trasy, dlatego przed stwierdzeniem, że „zdalny Immich” oznacza jeden tryb wydajności, porównaj identyczne działania.

LAN eliminuje większość zmienności trasy WAN

W przewodowej lub dobrze działającej sieci Wi-Fi LAN klient i serwer dzieli zwykle zaledwie kilka lokalnych przeskoków przełączających lub routujących. Czas RTT jest niski, a domownik kontroluje większość trasy, więc małe wywołania API i wiele żądań miniaturek może być obsługiwanych bez długiego oczekiwania na sieć.

Model połączeń bezpośrednich i przekazywanych przez przekaźnik opisany w artykule przechodzenie przez NAT pomaga wyjaśnić tę różnicę. Zdalny klient może łączyć się z tym samym serwerem przez bezpośredni tunel WAN albo za pośrednictwem przekaźnika, podczas gdy klient LAN korzysta po prostu z lokalnej trasy. Punkt końcowy aplikacji może być identyczny, nawet gdy warunki transportu są różne.

Szybsza sieć LAN nie dowodzi, że serwer działa prawidłowo przy każdym obciążeniu. Niskie opóźnienia lokalne mogą ukrywać nieefektywne żądania lub wolne nośniki, ponieważ oczekiwanie na sieć jest krótkie. Uwzględnij metryki serwera w porównaniu, aby diagnoza zdalnej trasy nie przesłoniła wąskiego gardła zaplecza, które wpływa na obie trasy.

Wysyłanie z domu staje się przepustowością pobierania zdalnego

Gdy osoba spoza domu otwiera zdjęcia przechowywane na domowym serwerze, serwer wysyła dane przez kierunek wysyłania domowego łącza internetowego. Wiele połączeń mieszkaniowych ma znacznie mniejszą przepustowość wysyłania niż lokalny Ethernet lub Wi-Fi, dlatego zdalne oryginały i duże podglądy mogą być ograniczone przepustowością, nawet gdy przeglądanie w sieci LAN jest natychmiastowe.

Wątek społeczności na temat zdalnego dostępu dla rodziny pokazuje, dlaczego gospodarstwa domowe oceniają więcej niż samą łączność: trasa musi być także prosta i niezawodna dla użytkowników nietechnicznych. Wydajność, uwierzytelnianie i wygoda użytkownika są częścią praktycznej zdalnej trasy.

Przepustowość nie jest właściwym wyjaśnieniem, gdy powolne są małe operacje sterujące metadanymi, filtrowanie lub logowanie, podczas gdy duże transfery osiągają oczekiwaną szybkość. Taki wzorzec silniej wskazuje na opóźnienia, routing żądań, działanie serwera proxy, DNS lub czas odpowiedzi serwera.

Serwery proxy i tunele dodają granice przetwarzania i konfiguracji

Zdalne żądanie może kończyć TLS na serwerze proxy, przechodzić przez inną sieć kontenerową lub podróżować przez zaszyfrowaną nakładkę sieciową, zanim dotrze do Immich. Prawidłowo skonfigurowane warstwy mogą powodować niewielkie opóźnienia, ale każda z nich wprowadza kolejne miejsce, w którym buforowanie, obsługa nagłówków, zasady limitów czasu, wybór trasy lub problemy z MTU mogą wpływać na konkretne żądania.

W raporcie użytkownika Immich z 2026 roku dotyczącym opóźnień filtrowania zdalnego ostatecznie zidentyfikowano problem z konfiguracją ścieżki punktu końcowego, po rozważeniu także wydajności przekaźnika. Przykład jest wartościowy, ponieważ dwa różne mechanizmy powodowały podobne objawy w rodzaju „zdalnie działa wolno”.

Nie zmieniaj technologii dostępu zdalnego na podstawie jednego wczytania strony. Najpierw ustal, czy problem dotyczy transferu, żądania API, uwierzytelniania czy nawiązywania połączenia. Odwrotny serwer proxy nie naprawi przeciążonego domowego łącza wysyłającego, a szybszy tunel nie naprawi wolnego zapytania do bazy danych.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Pamięć podręczna może sprawić, że testy LAN i zdalne nie będą porównywalne

Telefon w sieci LAN może mieć już zapisane w pamięci podręcznej miniatury, stan sesji, odpowiedzi DNS lub niedawno używane zasoby, podczas gdy test zdalny może rozpoczynać się z mniej wypełnioną pamięcią podręczną. Porównanie tych dwóch uruchomień może wyolbrzymić różnicę sieciową, ponieważ jeden klient pobiera z serwera mniej danych.

Wyjaśnienie ZimaSpace dotyczące opóźnień pamięci masowej podkreśla potrzebę kontrolowania stanu pamięci podręcznej i obciążenia podczas porównywania wydajności. Ta sama zasada dotyczy testowania tras: w miarę możliwości używaj tego samego konta, zestawu zasobów, klienta i stanu pamięci podręcznej.

Mechanizm LAN kontra WAN przestaje wyjaśniać rozbieżność, która pozostaje po wymuszeniu tej samej trasy w obu testach lub gdy sam czas odpowiedzi serwera rośnie identycznie. W takim przypadku zbadaj aplikację lub hosta, zamiast dalej optymalizować topologię sieci.

Przygotuj porównanie tras dla tych samych działań

Wybierz cztery działania: wczytaj ten sam album, otwórz to samo duże zdjęcie, wykonaj to samo znane wyszukiwanie i prześlij ten sam plik testowy. Zapisz czas zaobserwowany przez klienta, czas obsługi żądania przez serwer, jeśli jest dostępny, opóźnienie RTT, przepustowość transferu oraz informację, czy zdalna trasa jest bezpośrednia, obsługiwana przez proxy czy przekazywana przez przekaźnik.

Porównaj uruchomienia LAN i zdalne przy znanym stanie pamięci podręcznej, a następnie zmieniaj tylko jedną zmienną trasy naraz. Omówienie połączeń bezpośrednich i przekazywanych przez przekaźnik w Tailscale przedstawia użyteczny model klasyfikacji tras. Jeśli poprawiają się tylko duże transfery, silniejszym ograniczeniem jest przepustowość.

Uznaj diagnozę za potwierdzoną, gdy zmieniona trasa poprawia działanie przewidziane przez dany mechanizm bez zmiany obciążenia serwera. Zachowaj najprostszy projekt dostępu zdalnego, który spełnia wymagania rodziny dotyczące dostępu i wydajności; dodatkowe warstwy proxy, tunelu lub przekaźnika powinny istnieć z wyraźnego powodu związanego z dostępnością albo bezpieczeństwem.