Jak opóźnienie sieci wpływa na działanie Immich podczas importowania dużych bibliotek zdjęć z urządzeń mobilnych?

Opóźnienie sieciowe najbardziej wpływa na duże importy mobilne do Immich, gdy proces wymaga wielu operacji typu round trip, ponowień lub przeskoków przez zdalne usługi, a nie jednego nieprzerwanego transferu zbiorczego.

Łącze o dużej przepustowości może nadal działać wolno, jeśli każde żądanie musi czekać na długą podróż w obie strony, podczas gdy sieć LAN o małych opóźnieniach może szybko wykonywać operacje sterujące nawet przy niższej deklarowanej przepustowości. Po zaakceptowaniu zasobu generowanie miniatur, przetwarzanie metadanych i lokalne indeksowanie mogą jednak być kontynuowane bez udziału telefonu w krytycznej ścieżce, dlatego opóźnienie przesyłania i opóźnienie przetwarzania należy mierzyć osobno.

Opóźnienie i przepustowość ograniczają różne etapy importu

Przepustowość określa, jak szybko duże ładunki zdjęć i filmów mogą przejść przez łącze, gdy transfer jest stale aktywny. Opóźnienie określa, jak szybko może zakończyć się wymiana żądanie–odpowiedź, etap uwierzytelniania, ustanawianie połączenia lub ponowienie próby. Na jakość importu wpływa połączenie tych operacji, a nie tylko jeden z tych parametrów.

Wyjaśnienie firmy Tailscale dotyczące wyboru ścieżki i przekaźników pokazuje, dlaczego ścieżka sieciowa może zwiększać opóźnienie bez zmiany samego serwera Immich. Ścieżka bezpośrednia i ścieżka przez przekaźnik mogą docierać do tego samego punktu końcowego, ale mieć różne parametry podróży w obie strony i przepustowości.

Oznacza to, że przesyłanie wielu mniejszych plików może być bardziej podatne na narzut związany z podróżą w obie strony niż przesyłanie jednego dużego filmu o takim samym łącznym rozmiarze. Nie używaj pojedynczego wyniku testu prędkości do przewidywania czasu zakończenia, chyba że test odzwierciedla wzorzec żądań i kierunek rzeczywistego importu mobilnego.

Ponowienia prób zwielokrotniają koszt długiej podróży w obie strony

Utrata pakietów w sieci bezprzewodowej, przełączanie między sieciami komórkowymi, zmiany trasy VPN lub przeciążone łącza nadrzędne mogą wymuszać ponowne przesyłanie żądań albo segmentów. Na ścieżce o małych opóźnieniach odzyskiwanie może być prawie niezauważalne; na ścieżce o dużych opóźnieniach każde ponowienie dodaje kolejny czas oczekiwania i może sprawiać, że postęp wygląda na nierównomierny.

Rzeczywisty opis powolnego zdalnego dostępu do Immich jest przydatnym przykładem diagnostycznym, ponieważ komentujący oddzielili podejrzenie dotyczące ścieżki przez przekaźnik od problemu z konfiguracją punktu końcowego. Wniosek jest taki, aby przed obwinianiem samej przepustowości sprawdzić zarówno ścieżkę transportową, jak i sposób obsługi żądań przez aplikację.

Wyjaśnienie sieciowe traci na znaczeniu, gdy serwer otrzymuje zasoby ze stałą szybkością, ale kolejki zadań w tle pozostają wolne po zakończeniu transferu. Wtedy o gotowości decydują CPU, pamięć masowa, baza danych lub przetwarzanie uczenia maszynowego, a nie opóźnienie między telefonem a serwerem.

Zdalne uczenie maszynowe dodaje inną krawędź sieciową

Jeśli wnioskowanie uczenia maszynowego działa na innym hoście, indeksowanie zyskuje przeskok sieciowy między serwerem a usługą ML, którego może nie obejmować ścieżka mobilnego przesyłania. Gospodarstwo domowe może więc mieć szybkie przesyłanie zdjęć z telefonu, ale wolne kończenie wyszukiwania semantycznego, gdy usługa wnioskowania jest zdalna lub okresowo niedostępna.

Przykład zdalnego uczenia maszynowego pokazuje, że Immich ML można umieścić na innym komputerze w prywatnej sieci. Taka architektura może zmniejszyć obciążenie lokalnego CPU, ale zwiększa zależność od dostępności sieci i czasu podróży w obie strony między usługami.

Nie należy mylić tego przypadku ze zwykłym zdalnym wyświetlaniem. Jeśli host ML znajduje się w tej samej sieci LAN co serwer Immich, opóźnienie internetowe telefonu nie ma znaczenia dla tego etapu wnioskowania. Jeśli znajduje się za tunelem lub siecią WAN, tę ścieżkę usługi należy mierzyć niezależnie.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Ruch związany z importem może konkurować ze zdalnym użyciem interaktywnym

Duże przesyłanie zużywa przepustowość wysyłania lub pobierania w zależności od tego, gdzie względem serwera domowego znajduje się telefon. Gdy to samo ograniczone łącze WAN obsługuje również obrazy osi czasu, odpowiedzi API, kopie zapasowe lub inny ruch domowy, kolejkowanie na routerze albo na brzegu sieci ISP może zwiększać opóźnienie małych żądań interaktywnych.

Analiza ZimaSpace dotycząca opóźnienia pamięci masowej w Immich przedstawia analogiczny test przyczynowy: rywalizacja o współdzielony zasób ma znaczenie tylko wtedy, gdy dłuższy czas oczekiwania na ten zasób zbiega się z opóźnioną czynnością użytkownika. Tak samo analizuj sieć, zamiast zakładać, że każdy import ją wysyca.

Ten mechanizm przestaje wyjaśniać spowolnienie, gdy wykorzystanie WAN jest umiarkowane, czas podróży w obie strony pozostaje stabilny, a serwer wykazuje rosnące opóźnienie żądań lub pamięci masowej. Rywalizacja w sieci i na serwerze może występować jednocześnie, dlatego należy ustalić, które opóźnienie zmienia się jako pierwsze przy kontrolowanym obciążeniu.

Testuj import jako cztery osobne osie czasu

Użyj stałej partii zawierającej wiele małych zdjęć i kilka dużych filmów. Zarejestruj cztery osie czasu: transfer klient–serwer, akceptację przez serwer, przetwarzanie w tle oraz końcową gotowość wyszukiwania. Równolegle rejestruj opóźnienie podróży w obie strony, rzeczywistą szybkość transferu, oznaki retransmisji lub ponowień oraz odpowiednie wskaźniki zasobów serwera.

Porównaj tę samą partię w lokalnej sieci Wi-Fi lub przewodowej sieci LAN oraz na docelowej trasie zdalnej, bez zmiany ustawień serwera. Podczas interpretowania tunelu użyj ścieżek bezpośrednich i przez przekaźnik w Tailscale jako punktu odniesienia dla transportu. Jeśli czas transferu się wydłuża, ale przetwarzanie po stronie serwera pozostaje podobne, zmienną kontrolującą jest sieć.

Uznaj diagnozę sieciową za potwierdzoną dopiero wtedy, gdy kontrolowana zmiana ścieżki poprawi przewidywany etap, a pozostałe etapy pozostaną porównywalne. Takie dowody są silniejsze niż test prędkości, pojedynczy wysoki ping lub ogólne stwierdzenie, że zdalne przesyłanie zawsze działa wolniej.