Hoe je Immich benchmarkt met een reproduceerbare workload voor thuisservers

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Een herhaalbare Immich-benchmark legt de mediacohort, het clientpad, de cachestatus, overlappende achtergrondtaken en het gemeten eindpunt vast voordat er één variabele wordt gewijzigd.

Zonder die controles kan een snellere tweede run het gevolg zijn van opgewarmde gegevens in plaats van betere hardware, terwijl een inactieve test conflicten tijdens het importeren kan verbergen. Een bruikbare benchmark voor een thuisserver bootst de echte browse-, upload-, zoek- en herstelbehoeften van het huishouden in dezelfde volgorde na.

Definieer gebruikersresultaten voordat je metrieken verzamelt

Begin met waarneembare resultaten, zoals acceptatie van uploads, de tijd totdat een nieuwe foto doorzoekbaar wordt, het voltooien van tijdlijnminiaturen, het openen van het origineel, het starten van een video of het herstellen van een bruikbare bibliotheek. CPU-gebruik en schijfdoorvoer verklaren deze resultaten, maar zijn geen vervanging voor het resultaat dat de gebruiker ervaart.

Het Immich-datapad-artikel van ZimaSpace maakt onderscheid tussen uploadacceptatie, verwerkingsgereedheid, zoekselectie en geleverde media. Die structuur is nuttig omdat een benchmark één eindpunt moet timen in plaats van meerdere afhankelijke fasen samen te voegen tot een misleidend totaal.

Selecteer twee interactieve eindpunten en één achtergrondeindpunt. Stel voor elk een doelwaarde in en registreer zowel de mediaan als de latentie in de trage staart of het voltooiingspercentage. Een benchmark met veel niet-gerelateerde scores wordt moeilijk te interpreteren; een kleine set die aan een specifieke beslissing is gekoppeld, houdt het resultaat bruikbaar.

Leg de dataset, het clientpad en de beginstatus vast

Gebruik bij elke run dezelfde representatieve foto's en video's, inclusief indelingen en groottes die overeenkomen met de familiebibliotheek. Leg het account, het clientapparaat, de netwerkroute, de Immich-versie en de instellingen voor afgeleide bestanden vast. Zelfs een gewijzigde browsercache of wifi-route kan het configuratieverschil dat je test overschaduwen.

Een artikel over benchmarking van vectorzoekopdrachten benadrukt herhaalbare workloads voor embeddings, invoegen en ophalen bij het onderzoeken van de zoekprestaties van PostgreSQL. Immich is een bredere applicatie, maar het experimentele principe blijft hetzelfde: gecontroleerde invoer en gedefinieerde ophaalbewerkingen zijn nodig voordat tijdsverschillen een conclusie ondersteunen.

Maak een datasetmanifest met controlesommen van bestanden, aantallen, totale bytes, foto-indelingen, videoduren en verwachte zoekresultaten. Voeg een startchecklist toe voor opnieuw gestarte services, opwarmacties, taken in de wachtrij en concurrerende applicaties. Als de checklist verschilt, markeer de run dan als niet vergelijkbaar in plaats van deze mee te nemen in een gemiddelde.

Voer koude, warme en langdurige fasen uit

De koude fase laat initialisatie- en kosten voor eerste toegang zien. De warme fase laat hergebruik bij onmiddellijke herhaling zien. De langdurige fase combineert herhaalde interacties met een representatieve import of achtergrondwachtrij die lang genoeg duurt om thermische throttling, geheugendruk, opslagwachtrijen en resourceconcurrentie zichtbaar te maken.

Een communityrapport beschrijft een eerste slimme zoekopdracht die ongeveer vijf seconden duurde, tegenover ongeveer een halve seconde voor een onmiddellijke herhaling, terwijl het modelgeheugen veranderde. Die cijfers zijn geen benchmarkstandaard; ze laten zien waarom het middelen van koude en warme verzoeken de overgang verbergt die de test moet verklaren.

Voer elke fase minstens drie keer uit en bewaar de onbewerkte tijdstempels en resource-traces. Houd voor interactief werk de mediaan en een maat voor de trage staart bij, plus het aantal wachtrij-items per minuut voor achtergrondwerk. Stop de run als fouten, hevig swappen of thermische limieten de beoogde stabiele toestand ongeldig maken.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Gebruik een runformulier met één variabele

Schrijf de hypothese vóór de run op: het wijzigen van de databaseplaatsing, workerconcurrentie, geheugenlimiet, netwerkroute of accelerator moet één benoemd eindpunt verbeteren via één genoemd mechanisme. Houd al het overige gelijk. Zo voorkom je dat een upgrade met meerdere wijzigingen een sneller resultaat oplevert zonder verdedigbare oorzaak.

Een algemene knelpuntenanalyse legt uit dat CPU-, RAM-, opslag- en netwerkbeperkingen verschillende gebruikspatronen en gebruikerseffecten veroorzaken. Toegepast op Immich moeten ondersteunende metrieken zich consistent met het eindpunt ontwikkelen; de drukste grafiek wijst niet automatisch op de beperkende component.

Registreer de nulmeting en de gewijzigde resultaten voor de koude, warme en langdurige fasen en markeer ze vervolgens als geslaagd, mislukt of onbeslist. Wijs verbeteringen af die bij herhaling verdwijnen of fouten, instabiele temperaturen, verloren voortgang in de wachtrij of langer herstel veroorzaken. Bewaar het manifest en het runformulier zodat een toekomstige release eerlijk kan worden vergeleken.