Så här benchmarkar du Immich med en repeterbar hemserverarbetsbelastning

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Ett reproducerbart Immich-benchmarktest låser medieurvalet, klientvägen, cachestatusen, överlappningen av bakgrundsjobb och den endpoint som ska mätas innan en enda variabel ändras.

Utan dessa kontroller kan en snabbare andra körning bero på uppvärmda data snarare än bättre maskinvara, medan ett test i viloläge kan dölja konkurrens om resurser under import. Ett användbart benchmarktest för en hemmaserver återskapar hushållets verkliga behov av bläddring, uppladdning, sökning och återställning i samma sekvens.

Definiera användarresultat innan du samlar in mätvärden

Börja med observerbara resultat, till exempel accepterad uppladdning, tiden tills ett nytt foto blir sökbart, när tidslinjens miniatyrbilder är klara, när originalet öppnas, när en video startar eller när biblioteket har återställts till ett användbart skick. CPU-användning och diskgenomströmning förklarar dessa resultat, men ersätter inte det användarsynliga resultatet.

Artikeln om Immichs datapath från ZimaSpace skiljer mellan accepterad uppladdning, bearbetningsberedskap, sökurval och levererad media. Den strukturen är användbar eftersom ett benchmarktest måste mäta en endpoint i taget i stället för att blanda flera beroende steg till en missvisande totalsiffra.

Välj två interaktiva endpoints och en bakgrundsendpoint. Ange ett mål för godkänt resultat för varje endpoint och registrera medianen samt latenstiden eller slutförandegraden i den långsamma svansen. Ett benchmarktest med många orelaterade poäng blir svårt att tolka; ett litet urval kopplat till ett specifikt beslut gör resultatet användbart.

Lås datasetet, klientvägen och startläget

Använd samma representativa foton och videor i varje körning, inklusive format och storlekar som motsvarar familjens bibliotek. Lås kontot, klientenheten, nätverksvägen, Immich-versionen och inställningarna för derivat. Även en ändrad webbläsarcache eller Wi-Fi-väg kan överskugga konfigurationsskillnaden som testas.

En artikel om benchmarking av vektorsökning betonar reproducerbara arbetsbelastningar för embedding, infogning och hämtning vid analys av PostgreSQL:s sökprestanda. Immich är en bredare applikation, men den experimentella principen gäller även här: kontrollerade indata och definierade hämtningar krävs innan tidsskillnader kan ligga till grund för en slutsats.

Skapa ett datasetmanifest med filkontrollsummor, antal, totala byte, fotoformat, videolängder och förväntade sökresultat. Lägg till en startchecklista för omstartade tjänster, uppvärmningsåtgärder, köade jobb och konkurrerande applikationer. Om checklistan skiljer sig åt ska körningen märkas som icke jämförbar i stället för att tas med i ett genomsnitt.

Kör kalla, varma och långvariga faser

Den kalla fasen visar initieringskostnad och kostnad för första åtkomst. Den varma fasen visar återanvändning vid omedelbar upprepning. Den långvariga fasen blandar upprepade interaktioner med en representativ import eller bakgrundskö under tillräckligt lång tid för att avslöja termisk strypning, minnestryck, lagringsköer och resurskonkurrens.

En rapport från communityn beskriver en första smart sökning som tog ungefär fem sekunder och en omedelbar upprepning på omkring en halv sekund när modellminnet förändrades. Dessa siffror är ingen benchmarkstandard; de visar varför ett genomsnitt av kalla och varma förfrågningar döljer den övergång som testet behöver förklara.

Kör varje fas minst tre gånger och bevara råa tidsstämplar och resursloggar. Behåll medianen och ett mått på den långsamma svansen för interaktivt arbete samt antal köobjekt per minut för bakgrundsarbete. Avbryt körningen om fel, kraftig växling eller termiska gränser gör att det avsedda stabila tillståndet inte längre gäller.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Använd ett körschema med en enda variabel

Skriv hypotesen före körningen: en ändring av databasplacering, arbetarkonkurrens, minnesgräns, nätverksväg eller accelerator ska förbättra en namngiven endpoint genom en angiven mekanism. Håll allt annat konstant. Då undviker du att en uppgradering med flera ändringar ger ett snabbare resultat utan någon försvarbar orsak.

En generell flaskhalsanalys förklarar att begränsningar i CPU, RAM, lagring och nätverk ger olika användningsmönster och effekter för användaren. Tillämpat på Immich bör stödjande mätvärden förändras på ett sätt som stämmer med endpointen; det mest belastade diagrammet är inte automatiskt den begränsande komponenten.

Registrera baslinje- och förändrade resultat för kalla, varma och långvariga faser och markera godkänt, underkänt eller oklart. Förkasta förbättringar som försvinner vid upprepning eller orsakar fel, instabila temperaturer, förlorade köförlopp eller längre återställning. Bevara manifestet och körschemat så att en framtida version kan jämföras på ett ärligt sätt.