Hur många samtidiga användare klarar Immich innan det börjar gå långsammare?

Det finns inget användbart universellt antal samtidiga Immich-användare som alla hemmaservrar klarar, eftersom ”en användare” kan innebära inaktiv bläddring, ansiktssökning, en stor uppladdning, videouppspelning eller flera bakgrundsjobb samtidigt.

Kapaciteten bör mätas som den högsta återkommande hushållsbelastning som fortfarande uppfyller dina egna krav på svarstid och fel. Fastställ en lugn baslinje, återskapa realistiska blandade åtgärder, öka samtidigheten i kontrollerade steg och bevaka den första resursen som når sin gräns. Då får du ett försvarbart kapacitetsintervall för din hårdvara och ditt bibliotek i stället för en påhittad användargräns.

Definiera vad ”blir långsamt” betyder innan du räknar användare

Välj ett litet antal användarsynliga åtgärder som är viktiga i ditt hem: öppna tidslinjen, läsa in ett äldre album, söka, spela upp video och ladda upp en omgång. Bestäm vad ett fel innebär innan testet, till exempel oacceptabel fördröjning, tidsgränsöverskridningar, misslyckade uppladdningar, hackig uppspelning eller en kö som fortsätter att växa efter att användarna slutat.

Blanda inte förgrunds- och bakgrundsarbete utan att dokumentera det. Generering av miniatyrbilder, videotranskodning, ansiktsbearbetning, Smart Search, biblioteksskanningar, databasunderhåll och säkerhetskopiering kan förbruka samma CPU-, minnes-, disk- och nätverksresurser som aktiva användare. Ett test med ”fyra användare” under en stor import är en annan arbetsbelastning än fyra personer som bläddrar i ett stabilt bibliotek.

Dokumentera hårdvaran, Immich-versionen, databasens placering, lagringstypen, nätverksanslutningen, bibliotekets storlek och aktiva bakgrundsjobb tillsammans med varje resultat. Utan den kontexten går ett samtidighetsvärde inte att jämföra på ett meningsfullt sätt efter en uppgradering eller med en annan hemmaserver.

Mät en baslinje för en användare med bakgrundsarbete under kontroll

Börja när systemet befinner sig i ett känt tillstånd och mät en representativ användarresa. Registrera klientens svarstid tillsammans med serverns CPU-användning, minnestryck, diskfördröjning eller -utnyttjande, nätverkstrafik, databasaktivitet och eventuella Immich-arbetarköer som du kan observera.

Ett kapacitetsuttalande är bara meningsfullt när arbetsbelastningen, testets varaktighet och framgångskriterierna är tydliga. Använd arbetsbelastningsbaserad kapacitetstestning för att spara en baslinje för en användare och mät sedan hur fördröjning, genomströmning och fel förändras när samtidigheten ökar.

Om en användare redan upplever långsamhet ska du avbryta samtidighetstestet. Åtgärda flaskhalsen för en användare först; fler sessioner förstorar bara ett befintligt problem med lagring, databas, CPU, nätverk eller konfiguration och säger föga om serverns faktiska skalningsbeteende.

Öka realistisk samtidighet i kontrollerade steg

Lägg gradvis till användare eller skriptade klientsessioner och håll åtgärdsblandningen likartad mellan stegen. En användbar sekvens för ett hushåll kan vara att fördubbla antalet aktiva sessioner från en liten baslinje, men de exakta siffrorna är mindre viktiga än att bara ändra samtidigheten och hålla arbetsbelastningens definition konstant.

Definiera gränser för fördröjning, fel och genomströmning innan testet och använd realistiska flerstegsresor i stället för att överbelasta en enda slutpunkt. En realistisk arbetsbelastning för belastningstestning av Immich bör blanda de åtgärder som hushållet faktiskt utför i stället för att behandla upprepade inloggningsförfrågningar som ett mått på fot-serverns kapacitet.

Låt varje steg pågå tillräckligt länge för att cacheminnen, köer, databasanslutningar och lagringsbehov ska stabiliseras. Registrera både toppbelastningen och om systemet återhämtar sig när belastningen tas bort. En server som verkar fungera under en kortvarig topp men lämnar efter sig en växande job kö ligger redan över en hållbar nivå för den arbetsbelastningen.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Identifiera den första resursen som når sin gräns

När fördröjningen ökar ska du jämföra tidpunkten med resursbeteendet. CPU-mättnad under sökning eller maskininlärning tyder på beräkningsbelastning; hög diskfördröjning med måttlig CPU-användning pekar mot databas- eller medielagring; fulla nätverkslänkar pekar mot begränsningar för överföring eller fjärråtkomst; ökande databasväntetider eller anslutningstryck pekar mot datalagret.

Bakgrundsjobb kan förändra resultatet eftersom miniatyrbildsgenerering, transkodning, maskininlärning, skanningar, säkerhetskopiering eller omförsöksloopar kan förbruka resurser även när ingen aktivt bläddrar. Jämför testet med förhållanden med Immich-bakgrundsbelastning under kontroll, så att du inte misstar schemalagt arbete för en låg användargräns.

”Åtgärda” inte kapaciteten genom att dölja fel med längre tidsgränser för klienten. Ändra den begränsande resursen eller arbetsbelastningspolicyn – till exempel genom att schemalägga tunga jobb, förbättra lagringens placering, minska antalet samtidiga transkodningar eller lägga till beräkningskapacitet – och spela sedan upp exakt det misslyckade steget igen för att bevisa att flaskhalsen har flyttats eller försvunnit.

Fastställ ett praktiskt kapacitetsintervall för hushållet och testa igen

Definiera praktisk kapacitet som den högsta testade samtidigheten där alla nödvändiga användarresor håller sig inom dina förutbestämda gränser för fördröjning och fel, köerna återgår mot baslinjen efter testet och värdenheten behåller tillräcklig marginal för normalt bakgrundsarbete. Rapportera den som ett arbetsbelastningsspecifikt intervall, inte som ett maximivärde för Immich i allmänhet.

Upprepa gränssteget minst en gång från ett rent och jämförbart tillstånd och ta med de åtgärder som tidigare orsakade försämring. Testa sedan nästa högre steg tillräckligt kort för att bekräfta att gränsen fortfarande uppträder i samma resurs, utan att driva systemet in i en okontrollerad kö eller en händelse med lagringstryck.

Kör om samma test efter större Immich-uppgraderingar, databasflyttar, lagringsförändringar, hårdvaruförändringar eller en kraftig ökning av bibliotekets storlek. Ditt kapacitetsvärde är en egenskap hos det aktuella systemet och den aktuella arbetsbelastningen; att behålla testreceptet är mer värdefullt än att behålla ett gammalt användarantal.