Dlaczego Immich wydaje się mniej responsywny na różnych klientach?

Immich może działać wolniej na jednym kliencie, ponieważ renderowanie po stronie klienta, dekodowanie obrazów, stan pamięci podręcznej i ścieżka sieciowa wymagają dodatkowej pracy po odpowiedzi serwera.

Rodzina może przeglądać tę samą bibliotekę w przeglądarce na komputerze stacjonarnym, na starszym telefonie i na tablecie, podczas gdy serwer Immich, pamięć masowa i baza danych pozostają bez zmian. Jedno urządzenie może mimo to później otwierać osie czasu lub podglądy, ponieważ żądanie od początku do końca obejmuje pracę wykonywaną poza serwerem. Dlatego warto porównywać czas odpowiedzi serwera z dodatkowym czasem, jaki każdy klient poświęca na odbieranie, dekodowanie, buforowanie i wyświetlanie wyniku.

Klient zmienia zakres pracy wykonywanej po odpowiedzi Immich

Żądanie Immich nie kończy się w chwili, gdy serwer przygotuje JSON, adres URL miniatury lub odpowiedź zawierającą obraz. Klient nadal musi przetworzyć odpowiedź, zaktualizować interfejs, zaplanować renderowanie i reagować na działania użytkownika. Szybki serwer może więc współistnieć z klientem sprawiającym wrażenie powolnego, gdy urządzenie lub przeglądarka potrzebuje dodatkowego czasu na przekształcenie zwróconych danych w widoczny i interaktywny ekran.

To rozróżnienie jest szczególnie ważne w przeglądarkach, gdzie JavaScript, obsługa zdarzeń, obliczanie stylów, układ i znaczna część rysowania konkurują o pracę głównego wątku. Jeśli starszy telefon lub zajęta przeglądarka dłużej blokują ten wątek, stuknięcia i przewijanie mogą reagować z opóźnieniem, mimo że interfejs API Immich zakończył działanie mniej więcej w tym samym czasie co na szybszym komputerze stacjonarnym.

Dlatego porównywanie wyłącznie użycia procesora serwera lub opóźnienia bazy danych pomija część doświadczenia użytkownika. Omówienie klientów natywnych i przeglądarkowych w ZimaSpace pokazuje tę samą zasadę systemową: jeden backend może obsługiwać różne ścieżki wykonywania po stronie klienta. W przypadku Immich pierwsze pytanie diagnostyczne brzmi: czy opóźnienie występuje przed nadejściem odpowiedzi, czy dopiero po rozpoczęciu jej przetwarzania przez klienta?

Renderowanie obrazów może sprawić, że szybkie odpowiedzi wydają się powolne

Przeglądanie zdjęć wyraźniej uwidacznia różnice między klientami, ponieważ galeria to nie tylko tekst i metadane interfejsu API. Klient może żądać wielu miniatur lub większego podglądu, przechowywać część danych w pamięci, dekodować skompresowane obrazy, skalować je do rozmiaru widoku i składać wiele obrazów, gdy użytkownik nadal przewija. Zakres i czas tej lokalnej pracy mogą znacznie różnić się między urządzeniami, nawet jeśli żądają tego samego zasobu Immich.

Skompresowane formaty, takie jak JPEG i WebP, muszą przejść przez dekodowanie obrazu, zanim piksele będą mogły zostać wyświetlone. Szybsze procesory, lepiej zoptymalizowane dekodery, większa ilość dostępnej pamięci i różne silniki przeglądarek mogą skrócić ten etap. Na słabszym kliencie sieć może zakończyć pracę jako pierwsza, a dekodowanie i rysowanie stają się etapami, na które użytkownik faktycznie czeka.

W praktyce większy lub wyraźniejszy podgląd nie jest bezkosztowy tylko dlatego, że serwer może szybko go wygenerować. Obrazy o wyższej rozdzielczości wymagają więcej pamięci na zdekodowane piksele oraz większej ilości pracy przy skalowaniu i rysowaniu. Jeśli jeden klient zwalnia głównie podczas otwierania pełnych podglądów lub szybkiego przewijania gęstych osi czasu, a proste ekrany metadanych nadal reagują sprawnie, ścieżka renderowania obrazów jest bardziej prawdopodobnym wyjaśnieniem niż ogólne ograniczenie wydajności serwera.

Stan rozgrzanej pamięci podręcznej zmienia szybkość kolejnych wizyt

Klient, który wcześniej przeglądał album, może ponownie wykorzystać miniatury, skrypty, metadane lub zdekodowane zasoby, które nowy klient musi dopiero pobrać i przetworzyć. Dzięki temu drugie przejście trwa krócej, ale nie oznacza to, że serwer nagle zyskał większą wydajność. Oznacza to, że część ścieżki żądania zniknęła, ponieważ klient rozpoczął pracę ze stanem pamięci cieplejszym niż podczas pierwszego przejścia.

Rzeczywiste badania przeglądarek pokazują, że współczynniki trafień pamięci podręcznej różnią się między przeglądarkami, ich wersjami, urządzeniami i w czasie. Dokładne wartości procentowe z Facebooka nie są pomiarem Immich, ale mechanizm ma znaczenie: dwa klienty mogą łączyć się z tym samym serwerem, mając różne historie lokalnej pamięci podręcznej. Rozgrzana przeglądarka na komputerze może więc wydawać się znacznie bardziej responsywna niż nowo zainstalowana aplikacja na telefonie, bez dowodzenia, że którykolwiek z tych klientów jest z natury szybszy.

Pamięć podręczna może także prowadzić do mylących testów porównawczych przed i po zmianach. Wielokrotne odświeżanie tego samego albumu może usunąć konieczność pobierania i przetwarzania danych w kolejnych próbach, dlatego najszybszy wynik często mierzy ponowne wykorzystanie zasobów, a nie reprezentatywne obciążenie rodzinne. Jeśli celem jest porównanie klientów, zarejestruj zarówno ścieżkę z pustą pamięcią podręczną lub świeżo otwartą, jak i ścieżkę powtórną; różnica między nimi sama w sobie dostarcza użytecznych informacji o tym, w jakim stopniu każdy klient zależy od lokalnego ponownego wykorzystania zasobów.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Kiedy różnice między klientami przestają wyjaśniać opóźnienie

Różnice między klientami przestają być głównym wyjaśnieniem, gdy kilka różnych klientów zwalnia jednocześnie przy tym samym obciążeniu. Jeśli przeglądarka na komputerze stacjonarnym, telefon i tablet zaczynają dłużej czekać na dane osi czasu lub odpowiedzi z podglądami, a jednocześnie rosną użycie procesora serwera, opóźnienie pamięci masowej, aktywność bazy danych lub wykorzystanie sieci, wspólna infrastruktura staje się bardziej prawdopodobnym ograniczeniem responsywności niż implementacja któregokolwiek klienta.

Pomiar czasu od początku do końca powinien obejmować więcej niż komponent, który najłatwiej zmierzyć. Analiza opóźnień firmy Datadog pokazuje, że opóźnienie pełnego cyklu może obejmować transfer sieciowy, serwery proxy, pule połączeń i dekodowanie po stronie aplikacji, czyli elementy znajdujące się poza samą bazą danych. Ta sama zasada dotyczy Immich: prawidłowy wynik pomiaru bazy danych nie wyklucza opóźnienia w innym miejscu między rozpoczęciem żądania a wyrenderowaniem wyniku.

Przydatnym testem granicznym jest symetria. Jeśli tylko jeden klient działa wolno, podczas gdy inny w tej samej sieci LAN i z tym samym albumem pozostaje szybki, większą wagę należy przypisać wykonywaniu pracy przez klienta, pamięci podręcznej lub lokalnej sieci. Jeśli każdy klient przekracza mniej więcej ten sam próg opóźnienia w podobnym czasie, szczególnie podczas importowania, generowania miniatur, tworzenia kopii zapasowych lub innej aktywności hosta, wyjaśnienie przesuwa się od różnic między klientami w stronę wspólnego ograniczenia serwera, pamięci masowej lub sieci.

Użyj kontrolowanego testu klientów, aby znaleźć granicę

Wybierz jeden reprezentatywny album i zachowaj bez zmian wersję serwera, lokalizację sieciową, konto, zestaw obrazów oraz stan zadań w tle. Testuj każdego klienta osobno i zarejestruj trzy obserwowalne czasy: początkowe ładowanie osi czasu, otwieranie tego samego dużego podglądu oraz szybkie przewijanie ustalonego zakresu zdjęć. Zwróć także uwagę, czy serwer wykazuje skok obciążenia zasobów podczas każdego testu, ponieważ porównanie klientów jest nieważne, jeśli obciążenie backendu zmienia się między próbkami.

Uruchom każdy test raz ze świadomie pustym stanem pamięci podręcznej, a następnie ponownie od razu po pierwszej próbie. W testach wydajności często rozdziela się wyniki pierwszego i kolejnego wyświetlenia, ponieważ zapełnione pamięci podręczne usuwają część pracy z późniejszych żądań. W Immich różnica między stanem zimnym a rozgrzanym pokazuje, jak bardzo ponowne wykorzystanie zasobów zmienia doświadczenie, natomiast różnica między klientami przy tym samym stanie pamięci podręcznej ujawnia rozbieżności, które z większym prawdopodobieństwem są lokalne dla urządzenia lub aplikacji.

Traktuj różnicę jako zależną od klienta tylko wtedy, gdy powtarza się w co najmniej trzech próbach, a szybszy klient pozostaje szybszy przy porównywalnych warunkach serwera i sieci. Jeśli wszystkie klienty pogarszają działanie jednocześnie, przestań dostrajać klienta i przeanalizuj wspólną ścieżkę. Jeśli rozbieżności występują wyłącznie przy działaniach intensywnie wykorzystujących obrazy, skup się na dekodowaniu i renderowaniu. Jeśli różnica pojawia się tylko przy pierwszym uruchomieniu, bardziej uzasadnionym wnioskiem jest wpływ stanu pamięci podręcznej, a nie trwała wydajność serwera.