Immich-caching: hoe warme data herhaalde verzoeken verandert

Herhaalde Immich-verzoeken worden sneller wanneer modellen, databasepagina's, miniaturen en client-assets warm genoeg blijven om eerder laadwerk te vermijden.

De tweede zoekopdracht bewijst niet noodzakelijk dat de server meer capaciteit heeft gekregen. Mogelijk worden gegevens hergebruikt die door het eerste verzoek zijn voorbereid. Zinvolle tests moeten daarom vaststellen welke toestand behouden blijft en koud en warm gedrag afzonderlijk rapporteren.

Het eerste verzoek betaalt voor ontbrekende toestand

Na een herstart of lange periode van inactiviteit moet een Immich-verzoek mogelijk codepaden, modelgewichten, databasepagina's en miniatuurbestanden naar het actieve geheugen laden. Het kan ook verbindingsinstellingen en het ophalen van client-assets activeren. Latere verzoeken slaan een deel van dat werk over, ook al is hun zichtbare query identiek.

Een gebruikersrapport meet ongeveer vijf seconden voor een eerste slimme zoekopdracht en ongeveer een halve seconde voor een onmiddellijke herhaling, terwijl het GPU-geheugen toeneemt naarmate het model wordt geladen. De cijfers zijn configuratiespecifiek, maar de waargenomen volgorde laat zien waarom eerste en herhaalde zoekopdrachten verschillende systeemtoestanden vertegenwoordigen.

Leg de exacte koude toestand vast: een volledige containerherstart, een herstart van de machinelearningservice, gewiste clienttoestand of een gedefinieerd interval van inactiviteit. Deze omstandigheden zijn niet uitwisselbaar. Een resultaat dat alleen als ‘koud’ wordt aangeduid, kan niet onthullen of de vertraging werd veroorzaakt door modelresidentie, de paginacache van de server, het opzetten van de verbinding of hergebruik aan de clientzijde.

Warmte bestaat op verschillende onafhankelijke lagen

Er is geen enkele Immich-cache-instelling die elk herhaald verzoek verklaart. Het besturingssysteem kan bestandspagina's behouden, PostgreSQL kan warme gegevens opnieuw gebruiken, het machinelearningproces kan een geladen model behouden en browsers of mobiele apps kunnen miniaturen en applicatie-assets opnieuw gebruiken. Elke laag heeft een andere levensduur.

Een overzicht van cache-opwarming legt het algemene onderscheid uit: een warme cache levert behouden gegevens met minder vertraging, terwijl een koude cache ze uit een tragere primaire bron moet ophalen. In Immich kan die primaire bron permanente opslag zijn, en kunnen de ‘gegevens’ media, databasepagina's of modelbestanden zijn.

Gebruik selectieve resets. Herhaal de test in dezelfde browser en daarna met een nieuwe client; herstart alleen de machinelearningservice en daarna de applicatie; start ten slotte de host opnieuw op. De eerste reset die de lange vertraging terugbrengt, identificeert de laag waarvan de behouden toestand het meest heeft bijgedragen, hoewel meerdere lagen elkaar kunnen versterken.

Warme resultaten kunnen een capaciteitsgrens verbergen

Een kleine reeks herhaalde zoekopdrachten kan precies de benodigde pagina's en miniaturen in het geheugen houden. Die benchmark kan uitstekend lijken terwijl een grotere familiebibliotheek het geheugen overschrijdt en regelmatig missers veroorzaakt. Capaciteit wordt zichtbaar wanneer de werkset verandert, een andere service gegevens verdringt of een herstart tijdelijke toestand verwijdert.

De uitleg van het ZimaSpace-datapad maakt onderscheid tussen database-selectie en mediaweergave. Zo voorkom je dat een warme miniatuur een trage query maskeert of een gecachte query trage bestandslevering verbergt. Meet bij het onderzoeken van winst bij herhaalde verzoeken de resultaat-ID's en de weergegeven assets afzonderlijk.

Wissel af tussen verschillende queries en tijdlijngebieden in plaats van één item eindeloos te herhalen. Neem een representatief interval van inactiviteit en een concurrerende werklast op. Een server heeft nuttige capaciteit wanneer een aanvaardbare latentie binnen de verwachte werkset behouden blijft, niet alleen wanneer één warm pad in het geheugen blijft.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Rapporteer koude, warme en verstoorde runs samen

Stel een protocol in drie delen op. Voer eerst het endpoint uit na een gedocumenteerde koude toestand. Herhaal het vervolgens onmiddellijk zonder de invoer te wijzigen. Introduceer daarna de verwachte verstoring — inactiviteit, een andere container of een bredere queryset — en herhaal de test. Leg de mediaan en de latentie van de langzaamste staart vast in plaats van één stopwatchwaarde.

Een ondersteuningsthread over de eerste zoekopdracht meldt een aanvankelijke vertraging van tien tot vijftien seconden, gevolgd door vrijwel onmiddellijke herhalingen. Dit onderstreept dat beide verdelingen moeten worden behouden. Het stelt geen universele Immich-duur vast; modelkeuze, accelerator, geheugen, opslag en release kunnen het verschil allemaal beïnvloeden.

Sluit af met twee cijfers en één grens: de typische warme latentie, de typische koude latentie en de gebeurtenis waardoor de warmte verloren gaat. Als koud gedrag de doelstelling voor het huishouden overschrijdt, houd dan de benodigde toestand resident of verbeter dat laadpad. Als alleen kunstmatige koude tests mislukken, documenteer dan de geaccepteerde operationele toestand.