Immich-cachelagring: Så förändrar varm data upprepade förfrågningar
Upprepade Immich-förfrågningar blir snabbare när modeller, databassidor, miniatyrbilder och klientresurser förblir tillräckligt varma för att tidigare laddningsarbete ska kunna undvikas.
Den andra sökningen är inte nödvändigtvis ett bevis på att servern har fått högre kapacitet. Den kan återanvända data som förbereddes av den första förfrågningen, så meningsfull testning måste identifiera vilket tillstånd som består och rapportera kallt och varmt beteende separat.
Den första förfrågningen betalar för tillstånd som saknas
Efter en omstart eller en lång period av inaktivitet kan en Immich-förfrågning behöva läsa in kodvägar, modellvikter, databassidor och miniatyrfiler i det aktiva minnet. Den kan också utlösa anslutningsetablering och hämtning av klientresurser. Senare förfrågningar hoppar över en del av detta arbete, även om den synliga frågan är identisk.
En användarrapport mäter ungefär fem sekunder för en första smart sökning och omkring en halv sekund för en omedelbar upprepning, samtidigt som GPU-minnet ökar när modellen läses in. Siffrorna är specifika för konfigurationen, men den observerade sekvensen visar varför första sökningar och upprepade sökningar representerar olika systemtillstånd.
Dokumentera det exakta kalla tillståndet: fullständig omstart av containrar, omstart av maskininlärningstjänsten, rensat klienttillstånd eller ett definierat inaktivitetsintervall. Dessa förhållanden är inte utbytbara. Ett resultat som bara märkts ”kallt” kan inte visa om fördröjningen berodde på modellens närvaro i minnet, serverns sidcache, anslutningsetablering eller återanvändning på klientsidan.
Värme finns på flera oberoende lager
Det finns ingen enskild Immich-cacheinställning som förklarar varje upprepad förfrågning. Operativsystemet kan behålla filsidor, PostgreSQL kan återanvända data som finns i minnet, maskininlärningsprocessen kan behålla en inläst modell och webbläsare eller mobilappar kan återanvända miniatyrbilder och programresurser. Varje lager har en egen livslängd.
En översikt över cacheuppvärmning förklarar den allmänna skillnaden: en varm cache levererar sparade data med kortare fördröjning, medan en kall cache måste hämta dem från en långsammare primärkälla. I Immich kan primärkällan vara beständig lagring, och ”data” kan vara medier, databassidor eller modellfiler.
Använd selektiva återställningar. Upprepa sökningen i samma webbläsare och därefter från en ny klient; starta sedan om endast maskininlärningstjänsten och därefter applikationen; starta slutligen om värddatorn. Den första återställning som återskapar den långa fördröjningen identifierar det lager vars bevarade tillstånd bidrog mest, även om flera lager kan förstärka effekten.
Varma resultat kan dölja en kapacitetsgräns
Ett litet antal upprepade sökningar kan hålla exakt de sidor och miniatyrbilder som behövs kvar i minnet. Det riktmärket kan se utmärkt ut medan ett större familjebibliotek överskrider minnet och orsakar frekventa cachemissar. Kapaciteten syns när arbetsmängden ändras, en annan tjänst tränger undan data eller en omstart tar bort tillfälliga tillstånd.
ZimaSpaces förklaring av datasökvägen skiljer databasutval från visning av medier, vilket förhindrar att en varm miniatyrbild döljer en långsam fråga eller att en cachad fråga döljer långsam fillämning. Ta tid på resultatidentifierarna och de visade resurserna separat när du felsöker vinster med upprepade förfrågningar.
Variera mellan flera frågor och tidslinjeområden i stället för att upprepa ett enda objekt i all oändlighet. Inkludera ett representativt inaktivitetsintervall och en konkurrerande arbetsbelastning. En server har användbar kapacitet när acceptabel fördröjning kvarstår över den förväntade arbetsmängden, inte bara när en enda het sökväg förblir kvar i minnet.
Rapportera kalla, varma och störda körningar tillsammans
Bygg ett protokoll i tre delar. Kör först slutpunkten efter ett dokumenterat kallt tillstånd. Upprepa den sedan omedelbart utan att ändra indata. Inför därefter den förväntade störningen – inaktivitet, en annan container eller en bredare uppsättning frågor – och upprepa körningen. Samla in medianfördröjning och fördröjning i den långsamma svansen i stället för ett enda tidtagarvärde.
En supporttråd om den första sökningen rapporterar en inledande fördröjning på tio till femton sekunder följd av nästan omedelbara upprepningar, vilket understryker behovet av att bevara båda fördelningarna. Den fastställer inte en universell Immich-tid; modellval, accelerator, minne, lagring och version kan alla förändra skillnaden.
Avsluta med två siffror och en gränspunkt: typisk varm fördröjning, typisk kall fördröjning och den händelse som gör att värmen försvinner. Om det kalla beteendet överskrider hushållets mål bör du hålla nödvändigt tillstånd kvar i minnet eller förbättra den laddningsvägen. Om endast konstgjorda kalla tester misslyckas bör du dokumentera det accepterade driftförhållandet.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Vad är Immichs tillstånd, och vilka delar måste bevaras?
Immich-tillståndet omfattar original, databasrelationer, identitet, konfiguration och härledda filer; bevara varje del utifrån om den kan återskapas.
Hur hanterar Immich autentisering för lokala och fjärranslutna sessioner?
Immich använder serverbaserad identitet med klientsessioner, medan proxyhuvuden, ursprung och OIDC-omdirigeringar kan göra att lokalt och på distans beter sig olika.
Vad gör att Immichs sökningar eller frågeresultat blir långsammare när datamängden växer?
Immich-tillväxt kan göra index större, tränga undan ofta använda sidor, komplicera filter och fördröja mediedistributionen; separera dessa steg innan du finjusterar.
