Hoeveel gelijktijdige gebruikers kan Immich aan voordat het trager wordt?

Er bestaat geen universeel bruikbaar aantal gelijktijdige Immich-gebruikers dat elke thuisserver aankan, omdat “één gebruiker” kan staan voor inactief bladeren, zoeken op gezichten, een grote upload, video afspelen of meerdere achtergrondtaken tegelijk.

Capaciteit moet worden gemeten als de hoogste herhaalbare belasting voor een huishouden waarbij nog steeds aan je eigen criteria voor reactietijd en fouten wordt voldaan. Stel een rustige nulmeting vast, speel realistische gemengde acties opnieuw af, verhoog de gelijktijdigheid in gecontroleerde stappen en let op de eerste verzadigde resource. Zo krijg je een verdedigbare capaciteitsreeks voor je hardware en bibliotheek, in plaats van een verzonnen gebruikerslimiet.

Bepaal wat “trager worden” betekent voordat je gebruikers gaat tellen

Kies een kleine reeks zichtbare gebruikersacties die in jouw huishouden belangrijk zijn: de tijdlijn openen, een ouder album laden, zoeken, video afspelen en een batch uploaden. Bepaal vóór de test wat als mislukking geldt, zoals onaanvaardbare latentie, time-outs, mislukte uploads, haperingen bij het afspelen of een wachtrij die blijft groeien nadat gebruikers zijn gestopt.

Meng werk op de voorgrond en de achtergrond niet zonder dit vast te leggen. Het genereren van miniaturen, videotranscodering, gezichtsverwerking, Smart Search, bibliothe scans, databaseonderhoud en back-ups kunnen dezelfde CPU-, geheugen-, schijf- en netwerkresources verbruiken als actieve gebruikers. Een test met “vier gebruikers” tijdens een grote import is een andere belasting dan vier mensen die door een stabiele bibliotheek bladeren.

Leg bij elk resultaat de hardware, Immich-versie, plaats van de database, het opslagtype, de netwerkverbinding, de bibliotheekomvang en actieve achtergrondtaken vast. Zonder die context kan een gelijktijdigheidsgetal na een upgrade of bij vergelijking met een andere thuisserver niet zinvol worden geïnterpreteerd.

Meet een nulmeting voor één gebruiker met gecontroleerde achtergrondtaken

Start wanneer het systeem zich in een bekende toestand bevindt en meet een representatieve gebruikersroute voor één gebruiker. Leg de responstijd aan de clientzijde vast samen met server-CPU, geheugendruk, schijflatentie of -gebruik, netwerkdoorvoer, databaseactiviteit en alle Immich-werknemerswachtrijen die je kunt zien.

Een capaciteitsverklaring is alleen betekenisvol wanneer de belasting, testduur en succescriteria expliciet zijn. Gebruik capaciteitstests op basis van belasting om een nulmeting voor één gebruiker op te slaan en meet vervolgens hoe latentie, doorvoer en fouten veranderen naarmate de gelijktijdigheid toeneemt.

Als één gebruiker al traag is, stop dan de gelijktijdigheidstest. Los eerst het knelpunt voor één gebruiker op; meer sessies toevoegen vergroot alleen een bestaand probleem met opslag, database, CPU, netwerk of configuratie en zegt weinig over het werkelijke schaalgedrag van de server.

Verhoog de realistische gelijktijdigheid in gecontroleerde stappen

Voeg geleidelijk gebruikers of gescripte clientsessies toe en houd de actiemix tussen de stappen vergelijkbaar. Een bruikbare huishoudelijke reeks kan de actieve sessies vanaf een kleine nulmeting verdubbelen, maar de exacte aantallen zijn minder belangrijk dan alleen de gelijktijdigheid veranderen en de definitie van de belasting constant houden.

Bepaal vóór de test limieten voor latentie, fouten en doorvoer en gebruik realistische meerstapsroutes in plaats van één endpoint voortdurend te belasten. Een realistische belastingstest voor Immich moet de acties combineren die je huishouden daadwerkelijk uitvoert, in plaats van herhaalde inlogverzoeken te gebruiken als maatstaf voor de capaciteit van een fotoserver.

Houd elke stap lang genoeg aan zodat caches, wachtrijen, databaseverbindingen en de vraag naar opslag tot rust komen. Leg zowel de piek vast als de vraag of het systeem herstelt wanneer de belasting wordt verwijderd. Een server die er gedurende een korte piek acceptabel uitziet maar daarna een groeiende taakwachtrij overhoudt, zit voor die belasting al boven een duurzaam niveau.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Bepaal welke resource het eerst verzadigd raakt

Wanneer de latentie sterk toeneemt, vergelijk dan het tijdstip met het gedrag van de resources. CPU-verzadiging tijdens zoeken of machine learning wijst op rekenkrachtproblemen; hoge schijflatentie bij een bescheiden CPU-gebruik wijst op database- of mediaopslag; volledig benutte netwerkverbindingen wijzen op beperkingen bij overdracht of externe toegang; toenemende databasewachttijden of verbindingsdruk wijzen op de datalaag.

Achtergrondtaken kunnen het resultaat veranderen, omdat het genereren van miniaturen, transcoderen, machine learning, scans, back-ups of herhaallussen resources kunnen verbruiken, zelfs wanneer niemand actief aan het bladeren is. Vergelijk de test met gecontroleerde Immich-achtergrondbelasting, zodat je gepland werk niet aanziet voor een lage gebruikerslimiet.

“Los” capaciteitsproblemen niet op door fouten te verbergen met langere client-time-outs. Pas de beperkende resource of het beleid voor de belasting aan—bijvoorbeeld door zware taken in te plannen, de opslagplaatsing te verbeteren, gelijktijdige transcoderingen te beperken of rekenkracht toe te voegen—en speel vervolgens exact de mislukte stap opnieuw af om aan te tonen dat het knelpunt is verplaatst of verdwenen.

Stel een praktische capaciteitsreeks voor het huishouden vast en test opnieuw

Definieer praktische capaciteit als de hoogste geteste gelijktijdigheid waarbij alle vereiste gebruikersroutes binnen je vooraf opgestelde limieten voor latentie en fouten blijven, wachtrijen na de test terugkeren richting de nulmeting en de host voldoende marge behoudt voor normale achtergrondtaken. Rapporteer dit als een bereik dat specifiek is voor de belasting, niet als een maximum voor Immich in het algemeen.

Herhaal de grensstap ten minste één keer vanuit een schone, vergelijkbare toestand en neem de acties op die eerder voor verslechtering zorgden. Test daarna kort de eerstvolgende hogere stap om te bevestigen dat de grens opnieuw bij dezelfde resource zichtbaar wordt, zonder het systeem in een onbeheersbare wachtrij of opslagdruk te brengen.

Voer dezelfde test opnieuw uit na grote Immich-upgrades, het verplaatsen van de database, wijzigingen aan de opslag, hardwarewijzigingen of een sterke groei van de bibliotheek. Je capaciteitsgetal is een eigenschap van het huidige systeem en de huidige belasting; het testrecept bewaren is waardevoller dan een oude gebruikersaantallen bewaren.