Hoe je de prestaties van Immich meet zonder cache voor capaciteit aan te zien

De capaciteit van Immich moet worden gemeten met herhaalde koude, warme en langdurige workloads, omdat één snelle run uit de cache het echte verzadigingspunt van het systeem kan verhullen.

Een thuisserver kan een tijdlijn of album extreem snel laten aanvoelen nadat dezelfde miniaturen, databasepagina's en applicatiegegevens al eerder zijn gebruikt. Dat resultaat bewijst dat het warme pad efficiënt is, maar niet dat het systeem een grotere familiebibliotheek of meer gelijktijdige activiteit kan volhouden. Een bruikbare capaciteitstest moet de cachestatus beheersen, de werklast vergroten, runs herhalen en een meetbare stopconditie definiëren.

Cachesnelheid is niet hetzelfde als capaciteit

Capaciteit beschrijft hoeveel representatief werk een Immich-systeem kan volhouden voordat latentie, wachtrijen of fouten onaanvaardbaar worden. Cachesnelheid beantwoordt een beperktere vraag: hoe snel kan het systeem werk herhalen nadat nuttige gegevens of gegenereerde assets al binnen handbereik zijn? Als een benchmark hetzelfde album of dezelfde tijdlijn herhaalt, kunnen die twee vragen identiek lijken, ook al meten ze verschillende bedrijfsomstandigheden.

Het verschil is eenvoudig te zien bij webprestaties, waar tijden voor de eerste en herhaalde weergave uiteen kunnen lopen doordat latere verzoeken gecachte bronnen opnieuw gebruiken. Immich biedt extra mogelijkheden voor warm gedrag, omdat miniaturen, previews, databasepagina's, metagegevens van het bestandssysteem, de cache van het besturingssysteem en clientassets allemaal opnieuw kunnen worden gebruikt. Een herhaalde run kan daardoor werk wegnemen dat een groeiende of nieuw geopende bibliotheek nog steeds moet uitvoeren.

Dit is dezelfde reden waarom een cachegerichte Home Assistant-test misleidend kan zijn wanneer herhaalde verzoeken het grootste deel van de steekproef vormen; ZimaSpace's bespreking van cachelagen voor herhaalde verzoeken is ook van toepassing op de meetlogica hier. Leg voor Immich de warme prestaties vast, maar label ze als een afzonderlijk pad in plaats van ze te behandelen als de algemene capaciteit van de server.

Splits koude, warme en stabiele runs

Begin met het definiëren van de toestand voordat je de stopwatch indrukt. Een koude run moet werk omvatten dat niet zojuist is herhaald, zoals het openen van een andere datumreeks of assetset nadat caches minder gelegenheid hebben gehad om te helpen. Een warme run herhaalt bewust een bekend pad. Een run in stabiele toestand houdt representatieve activiteit lang genoeg gaande om achtergrondwerk, het hergebruik van resources en wachtrijen zichtbaar te maken die een korte uitbarsting mogelijk nooit laat zien.

Ook het opwarmen zelf kan misleidend zijn. Percona beschrijft situaties waarin een database opgewarmd lijkt terwijl vertraagde achtergrondprocessen de prestaties nog blijven beïnvloeden. Daardoor arriveert de stabiele toestand later dan de eerste snelle query's. Ook bij Immich kan browsen op de voorgrond samengaan met databaseactiviteit, werk aan miniaturen, indexering of andere taken in de wachtrij, afhankelijk van wat de bibliotheek op dat moment doet.

Voer voor een test van een thuisserver elke fase afzonderlijk uit in plaats van ze samen te middelen. Noteer of achtergrondtaken inactief of actief zijn, houd het client- en netwerkpad constant en herhaal dezelfde fase meerdere keren. Als de warme run snel is, maar langdurige activiteit de latentie of wachtrijdiepte geleidelijk verhoogt, is het tweede resultaat het betere signaal voor capaciteitsplanning.

Maak de werkgrootte groter dan de eenvoudig te cachen set

Een benchmark die dezelfde twintig foto's opent, is meestal te klein om een capaciteitsvraag over een familiebibliotheek te beantwoorden. Het besturingssysteem, de database, de client en de opslagstack kunnen een kleine actieve set dicht bij de processor houden, terwijl echt gebruik heen en weer springt tussen maanden, personen, albums, zoekresultaten en video's. De testset moet daarom groot en gevarieerd genoeg zijn, zodat niet elke bewerking profiteert van dezelfde recent gebruikte gegevens.

De praktijk van databasebenchmarks maakt het onderscheid expliciet: wanneer een test opslag of koud gedrag wil onderzoeken, kan achtergebleven cache de oefening veranderen in een test van cacheprestaties. Je hoeft niet elke cachelaag op een productieserver met Immich te legen om iets nuttigs te leren, maar je hebt wel een workload nodig waarvan de werkgrootte breder is dan één steeds opnieuw gebruikt scherm.

Kies meerdere datumreeksen, albums, zoekopdrachten en assettypen die lijken op normaal huishoudelijk gebruik en roteer ertussen in plaats van één weergave voortdurend te belasten. Houd die workloaddefinitie gelijk bij vergelijkingen tussen hardware of configuraties. Als een wijziging alleen een kleine, herhaalde subset verbetert terwijl bredere navigatie onder belasting nog steeds verslechtert, heeft die wijziging het warme pad verbeterd zonder de bruikbare capaciteitsgrens te verschuiven.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Meet percentielen en herhaal de test

Eén gemiddelde kan de momenten verbergen die gebruikers daadwerkelijk opmerken. Als negen verzoeken snel zijn en het tiende blijft hangen terwijl een wachtrij groeit of de opslag druk bezig is, kan het gemiddelde er nog steeds goed uitzien. Leg minimaal het mediane gedrag vast en daarnaast een percentiel van de staart, zoals p95. Combineer de latentie vervolgens met doorvoer, het aantal fouten, de achterstand van taken, CPU-gebruik, geheugendruk en opslagactiviteit, zodat de vertraging in context kan worden geplaatst.

Praktische benchmarkanalyse adviseert om p50, p95, p99 en variantie te rapporteren in plaats van op één run te vertrouwen, vooral bij toestandsafhankelijke systemen waar cacheverwijdering, compaction of achtergrondactiviteit later zichtbaar kan worden. Immich-tests hoeven geen laboratoriumnauwkeurigheid te hebben, maar ze moeten wel genoeg herhalingen bevatten om een herhaalbare limiet te onderscheiden van een toevallig rustige periode.

Voer hetzelfde scenario bij elk belastingsniveau minstens meerdere keren uit en bewaar de ruwe waarnemingen in plaats van alleen de beste run. Een capaciteitsclaim wordt geloofwaardiger wanneer p95 bij herhaalde runs stabiel blijft en de server de taken in de wachtrij tussen de meetvensters verwerkt. Als de resultaten sterk schommelen, onderzoek dan de ongecontroleerde variabele voordat je concludeert dat meer gebruikers, meer foto's of snellere hardware de bovengrens hebben veranderd.

Gebruik een Immich-capaciteitsprotocol met een stopconditie

Begin met één representatieve clientworkload en leg een baseline vast nadat het systeem de toestand heeft bereikt die je wilt testen. Verhoog daarna één variabele tegelijk: meer gelijktijdig browsen, uploaden, zoeken of achtergrondverwerking, terwijl bibliotheek, clientmix, netwerkpad en serverconfiguratie ongewijzigd blijven. Noteer bij elke stap de p50- en p95-latentie, het aantal geslaagde bewerkingen per minuut, fouten, groei van de wachtrij en de belangrijkste serverresource die de verzadiging nadert.

Met deze aanpak vermijd je de veelgemaakte fout om conclusies te trekken uit één korte run. Richtlijnen voor prestatietests waarschuwen tegen conclusies op basis van één run, omdat opwarming, cachestatus, achtergrondwerk en normale systeemruis een steekproef kunnen domineren. Herhaal elk belastingsniveau totdat de trend stabiel genoeg is om uit te leggen, niet alleen gemakkelijk genoeg om te citeren.

Leg vóór het testen een stopregel vast. Een praktische vuistregel voor een homelab is om de huidige configuratie als verzadigd te beschouwen wanneer de p95-latentie gedurende drie opeenvolgende meetvensters boven ongeveer tweemaal de onbelaste baseline blijft, of wanneer fouten of de achterstand van taken blijven groeien in plaats van te herstellen; dit is een testheuristiek en geen limiet van Immich. Het bruikbare capaciteitsgetal is het laatste belastingsniveau onder die grens, gemeten met hetzelfde protocol voor koude, warme en stabiele runs.