Så mäter du Immich-prestanda utan att förväxla cache med kapacitet

Immichs kapacitet bör mätas med upprepade kalla, varma och långvariga arbetsbelastningar, eftersom en snabb cachad körning kan dölja systemets verkliga mättnadspunkt.

En hemmaserver kan få en tidslinje eller ett album att kännas extremt snabbt efter att samma miniatyrbilder, databassidor och programdata redan har använts. Det resultatet visar att den varma sökvägen är effektiv, inte att systemet kan hantera ett större familjebibliotek eller mer samtidig aktivitet under längre tid. Ett användbart kapacitetstest måste kontrollera cachetillståndet, utöka arbetsmängden, upprepa körningarna och definiera ett mätbart stoppvillkor.

Cachens hastighet är inte samma sak som kapacitet

Kapacitet beskriver hur mycket representativt arbete ett Immich-system kan upprätthålla innan latens, köer eller fel blir oacceptabla. Cachens hastighet besvarar en snävare fråga: hur snabbt kan systemet upprepa arbete efter att användbara data eller genererade resurser redan finns nära till hands? Om ett benchmark upprepar samma album eller tidslinje kan de två frågorna se identiska ut, trots att de mäter olika driftförhållanden.

Skillnaden syns tydligt i webbprestanda, där tider för första visningen och upprepade visningar kan skilja sig eftersom senare förfrågningar återanvänder cachade resurser. Immich har ytterligare möjligheter till varm körning, eftersom miniatyrbilder, förhandsvisningar, databassidor, filsystemmetadata, operativsystemets cache och klientresurser alla kan återanvändas. En upprepad körning kan därför eliminera arbete som ett växande eller nyligen öppnat bibliotek fortfarande måste utföra.

Det är samma anledning till att ett cachefokuserat Home Assistant-test kan bli missvisande när upprepade förfrågningar dominerar urvalet; ZimaSpaces diskussion om cachelager för upprepade förfrågningar gäller även mätlogiken här. För Immich bör du registrera varm prestanda, men märka den som en separat sökväg i stället för att behandla den som serverns allmänna kapacitet.

Separera kalla, varma och stabila körningar

Börja med att definiera tillståndet innan du startar tidtagningen. En kall körning bör omfatta arbete som inte nyss har upprepats, till exempel att öppna ett annat datumintervall eller en annan uppsättning resurser efter att cachelagren haft mindre möjlighet att hjälpa till. En varm körning upprepar medvetet en känd sökväg. En körning i stabilt tillstånd håller den representativa aktiviteten igång tillräckligt länge för att synliggöra bakgrundsarbete, återanvändning av resurser och köer som en kort belastning kanske aldrig avslöjar.

Även uppvärmningen kan vara missvisande. Percona beskriver fall där en databas verkar vara uppvärmd samtidigt som fördröjda bakgrundsprocesser fortsätter att förändra prestandan, så stabilt tillstånd infaller senare än de första snabba frågorna. Immich kan på liknande sätt köra användaraktivitet parallellt med databasarbete, miniatyrbildsarbete, indexering eller andra köade jobb, beroende på vad biblioteket gör vid tillfället.

För ett hemmaservertest bör du köra varje fas separat i stället för att slå ihop dem till ett genomsnitt. Notera om bakgrundsjobb är inaktiva eller aktiva, håll klient och nätverkssökväg konstanta och upprepa samma fas flera gånger. Om den varma körningen är snabb men långvarig aktivitet gradvis höjer latensen eller könivån är det senare resultatet en bättre signal för kapacitetsplanering.

Gör arbetsmängden större än den lättcachade mängden

Ett benchmark som öppnar samma tjugo foton är vanligtvis för litet för att besvara en kapacitetsfråga om ett familjebibliotek. Operativsystemet, databasen, klienten och lagringsstacken kan hålla en liten het mängd nära processorn, medan verklig användning växlar mellan månader, personer, album, sökresultat och videor. Testmängden bör därför vara tillräckligt stor och varierad för att inte varje operation ska dra nytta av samma nyligen använda data.

Metoder för databasbenchmarking gör skillnaden tydlig: när ett test ska undersöka lagring eller kallt beteende kan kvarvarande cache förvandla övningen till ett test av cacheprestanda i stället. Du behöver inte tömma varje cachelager på en produktionsserver med Immich för att lära dig något användbart, men du behöver en arbetsbelastning vars arbetsmängd är bredare än en enda skärm som återanvänds om och om igen.

Välj flera datumintervall, album, sökningar och resurstyp­er som liknar normal hushållsanvändning, och växla sedan mellan dem i stället för att belasta en enda vy. Behåll samma arbetsbelastningsdefinition när du jämför hårdvara eller konfigurationer. Om en förändring bara förbättrar en liten upprepad del medan den bredare navigeringen fortfarande försämras under belastning har den förbättrat den heta sökvägen utan att flytta den användbara kapacitetsgränsen.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Mät percentiler och upprepa testet

Ett enda genomsnitt kan dölja de ögonblick som användarna faktiskt märker. Om nio förfrågningar är snabba och den tionde stannar upp medan en kö byggs upp eller lagringen är upptagen kan medelvärdet ändå se respektabelt ut. Registrera åtminstone medianbeteendet och en svanspercentil som p95, och koppla sedan latensen till genomströmning, antal fel, eftersläpning i jobb, processor, minnesbelastning och lagringsaktivitet så att fördröjningen får ett sammanhang.

Praktisk benchmarkanalys rekommenderar att rapportera p50, p95, p99 och variation i stället för att lita på en enda körning, särskilt för tillståndsbaserade system där cacheutkastning, komprimering eller bakgrundsaktivitet kan uppträda senare. Immich-tester behöver inte ha laboratorieprecision, men de behöver tillräckligt många upprepningar för att skilja en återkommande gräns från ett tillfälligt lugnt intervall.

Kör samma scenario åtminstone flera gånger vid varje belastningsnivå och behåll de råa observationerna i stället för att endast spara det bästa försöket. Ett kapacitetsanspråk blir mer trovärdigt när p95 förblir stabilt mellan körningarna och servern hinner tömma köade jobb mellan mätintervallen. Om resultaten varierar kraftigt bör du undersöka den okontrollerade variabeln innan du slår fast att fler användare, fler foton eller snabbare hårdvara har förändrat taket.

Använd ett kapacitetsprotokoll för Immich med ett stoppvillkor

Börja med en representativ klientarbetsbelastning och samla in ett basvärde efter att systemet nått det tillstånd du avser att testa. Öka sedan en variabel i taget: fler samtidiga bläddringar, uppladdningar, sökningar eller bakgrundsprocesser, medan bibliotek, klientblandning, nätverkssökväg och serverkonfiguration hålls fasta. Vid varje steg registrerar du p50- och p95-latens, lyckade operationer per minut, fel, köökning och den huvudsakliga serverresurs som närmar sig mättnad.

Detta tillvägagångssätt undviker det vanliga misstaget att dra slutsatser från en enda kort körning. Riktlinjer för prestandatestning varnar för slutsatser från en enda körning, eftersom uppvärmning, cachetillstånd, bakgrundsarbete och normalt systembrus kan dominera ett urval. Upprepa varje belastningsnivå tills riktningen är tillräckligt stabil för att kunna förklaras, inte bara tillräckligt bekväm för att citeras.

Använd en fastställd stoppregel innan testningen börjar. En praktisk tumregel för ett hemmalabb är att kalla den aktuella konfigurationen mättad när p95-latensen ligger kvar över ungefär det dubbla av den obelastade baslinjen under tre mätintervall i följd, eller när fel eller eftersläpning i jobb fortsätter att växa i stället för att återhämta sig; detta är en testheuristik, inte en Immich-gräns. Det användbara kapacitetstalet är den senaste belastningsnivån under den gränsen, uppmätt med samma protokoll för kalla, varma och stabila körningar.