Buforowanie Immich: jak ciepłe dane zmieniają powtarzające się żądania

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.

Immich Caching: How Warm Data Changes Repeated Requests

Powtarzające się żądania Immich stają się szybsze, gdy modele, strony bazy danych, miniatury i zasoby klienta pozostają wystarczająco „rozgrzane”, aby uniknąć ponownego wykonywania wcześniejszych operacji ładowania.

Drugie wyszukiwanie nie musi świadczyć o tym, że serwer zyskał większą wydajność. Może ponownie wykorzystać dane przygotowane przez pierwsze żądanie, dlatego miarodajne testy muszą określać, który stan pozostaje zachowany, oraz osobno przedstawiać zachowanie w stanie zimnym i ciepłym.

Pierwsze żądanie ponosi koszt brakującego stanu

Po ponownym uruchomieniu lub długim okresie bezczynności żądanie Immich może wymagać załadowania ścieżek kodu, wag modelu, stron bazy danych i plików miniatur do aktywnej pamięci. Może również uruchomić konfigurację połączenia i pobieranie zasobów klienta. Kolejne żądania pomijają część tych operacji, mimo że ich widoczne zapytanie jest identyczne.

Relacja użytkownika wskazuje około pięciu sekund dla pierwszego wyszukiwania inteligentnego i około pół sekundy dla natychmiastowego powtórzenia, podczas gdy użycie pamięci GPU rośnie w trakcie ładowania modelu. Wartości zależą od konfiguracji, ale zaobserwowana sekwencja pokazuje, dlaczego pierwsze i powtarzane wyszukiwania reprezentują różne stany systemu.

Zapisz dokładny warunek zimnego startu: pełne ponowne uruchomienie kontenera, ponowne uruchomienie usługi uczenia maszynowego, wyczyszczenie stanu klienta lub określony czas bezczynności. Warunki te nie są zamienne. Wynik opisany wyłącznie jako „zimny” nie ujawnia, czy opóźnienie wynikało z obecności modelu w pamięci, pamięci podręcznej stron serwera, konfiguracji połączenia czy ponownego wykorzystania po stronie klienta.

Rozgrzanie występuje na kilku niezależnych warstwach

Nie istnieje jeden przełącznik pamięci podręcznej Immich, który wyjaśnia każde powtarzające się żądanie. System operacyjny może zachowywać strony plików, PostgreSQL może ponownie wykorzystywać często używane dane, proces uczenia maszynowego może przechowywać załadowany model, a przeglądarki lub aplikacje mobilne mogą ponownie wykorzystywać miniatury i zasoby aplikacji. Każda z tych warstw ma inny czas życia.

Przegląd rozgrzewania pamięci podręcznej wyjaśnia ogólną różnicę: rozgrzana pamięć podręczna udostępnia zachowane dane z mniejszym opóźnieniem, natomiast zimna pamięć podręczna musi pobrać je z wolniejszego źródła podstawowego. W Immich tym źródłem może być pamięć trwała, a „danymi” mogą być multimedia, strony bazy danych lub pliki modelu.

Stosuj selektywne resetowanie. Powtórz test w tej samej przeglądarce, a następnie użyj nowego klienta; uruchom ponownie tylko usługę uczenia maszynowego, potem aplikację, a na końcu uruchom ponownie hosta. Pierwszy reset, po którym wraca długie opóźnienie, wskazuje warstwę, której zachowany stan miał największy udział w poprawie, choć kilka warstw może się wzajemnie wzmacniać.

Ciepłe wyniki mogą ukrywać granicę wydajności

Niewielki zestaw powtarzanych wyszukiwań może utrzymywać dokładnie potrzebne strony i miniatury w pamięci. Taki test może wyglądać doskonale, podczas gdy większa biblioteka przekracza dostępną pamięć i powoduje częste braki trafień. Ograniczenie pojemności ujawnia się, gdy zmienia się zestaw roboczy, inna usługa wypiera dane lub ponowne uruchomienie usuwa stan tymczasowy.

Wyjaśnienie ścieżki danych ZimaSpace rozdziela wybór danych w bazie od wyświetlania multimediów, co zapobiega maskowaniu wolnego zapytania przez ciepłą miniaturę lub maskowaniu powolnego dostarczania plików przez buforowane zapytanie. Podczas diagnozowania korzyści z powtarzanych żądań mierz osobno identyfikatory wyników i wyświetlane zasoby.

Zmieniaj kilka zapytań i obszarów osi czasu zamiast bez końca powtarzać jeden element. Uwzględnij reprezentatywny okres bezczynności i konkurencyjne obciążenie. Serwer ma użyteczną wydajność wtedy, gdy akceptowalne opóźnienie utrzymuje się dla oczekiwanego zestawu roboczego, a nie tylko wtedy, gdy jedna często używana ścieżka pozostaje w pamięci.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Raportuj razem przebiegi zimne, ciepłe i zakłócone

Opracuj trzyczęściowy protokół. Najpierw uruchom punkt końcowy po udokumentowaniu warunku zimnego startu. Następnie powtórz test natychmiast, nie zmieniając danych wejściowych. Na koniec wprowadź oczekiwane zakłócenie — czas bezczynności, inny kontener lub szerszy zestaw zapytań — i powtórz test. Rejestruj medianę oraz opóźnienie w najwolniejszym ogonie rozkładu, a nie pojedynczy pomiar stoperem.

Wątek pomocy dotyczący pierwszego wyszukiwania opisuje początkowe opóźnienie wynoszące od dziesięciu do piętnastu sekund, po którym kolejne wyszukiwania są niemal natychmiastowe, co potwierdza potrzebę zachowania obu rozkładów. Nie ustanawia to uniwersalnego czasu działania Immich; różnice mogą wynikać z wyboru modelu, akceleratora, pamięci, pamięci masowej i wersji.

Zakończ raport dwiema wartościami i jedną granicą: typowym opóźnieniem w stanie ciepłym, typowym opóźnieniem w stanie zimnym oraz zdarzeniem, które powoduje utratę rozgrzania. Jeśli zachowanie w stanie zimnym nie spełnia docelowych wymagań gospodarstwa domowego, utrzymuj niezbędny stan w pamięci lub usprawnij tę ścieżkę ładowania. Jeśli tylko sztuczne testy zimnego startu kończą się niepowodzeniem, udokumentuj zaakceptowany warunek operacyjny.