Quanti utenti simultanei può gestire Immich prima di rallentare?

Non esiste un numero universale e utile di utenti Immich simultanei che ogni home server possa gestire, perché “un utente” può significare navigazione inattiva, ricerca dei volti, un caricamento di grandi dimensioni, riproduzione video o diversi processi in background simultaneamente.

La capacità dovrebbe essere misurata come il carico domestico massimo ripetibile che soddisfa ancora i propri criteri di tempo di risposta e di errore. Stabilite una baseline con il sistema inattivo, riproducete azioni miste realistiche, aumentate la concorrenza gradualmente e monitorate la prima risorsa che raggiunge la saturazione. In questo modo otterrete un intervallo di capacità difendibile per il vostro hardware e la vostra libreria, invece di un limite di utenti arbitrario.

Definite cosa significa “rallentare” prima di contare gli utenti

Scegliete un piccolo insieme di azioni visibili all’utente che contano nella vostra abitazione: apertura della timeline, caricamento di un album meno recente, ricerca, riproduzione video e caricamento di un gruppo di file. Prima del test, stabilite cosa costituisce un problema, ad esempio latenza inaccettabile, timeout, caricamenti non riusciti, interruzioni della riproduzione o una coda che continua a crescere dopo che gli utenti hanno smesso.

Non mescolate il lavoro in primo piano e quello in background senza registrarlo. La generazione delle miniature, la transcodifica dei video, l’elaborazione dei volti, Smart Search, le scansioni della libreria, la manutenzione del database e i backup possono consumare le stesse risorse di CPU, memoria, disco e rete degli utenti attivi. Un test con “quattro utenti” durante una grande importazione rappresenta un carico diverso rispetto a quattro persone che navigano in una libreria stabile.

Registrate con ogni risultato l’hardware, la versione di Immich, la posizione del database, il tipo di storage, il collegamento di rete, le dimensioni della libreria e i processi in background attivi. Senza questo contesto, un numero di utenti simultanei non può essere confrontato in modo significativo dopo un aggiornamento o con un altro home server.

Misurate una baseline con un utente e il lavoro in background sotto controllo

Iniziate quando il sistema si trova in uno stato noto e misurate un percorso rappresentativo di un utente. Acquisite il tempo di risposta del client insieme all’utilizzo della CPU, alla pressione sulla memoria, alla latenza o all’utilizzo del disco, al throughput di rete, all’attività del database e alle eventuali code dei processi Immich osservabili.

Un’indicazione sulla capacità è significativa solo quando il carico di lavoro, la durata del test e i criteri di successo sono espliciti. Utilizzate i test della capacità basati sul carico di lavoro per salvare una baseline con un utente, quindi misurate come cambiano latenza, throughput ed errori all’aumentare della concorrenza.

Se un solo utente è già lento, interrompete il test di concorrenza. Risolvete prima il collo di bottiglia del singolo utente: aggiungere altre sessioni amplifica soltanto un problema già esistente di storage, database, CPU, rete o configurazione e fornisce poche informazioni sul reale comportamento di scalabilità del server.

Aumentate la concorrenza realistica in modo controllato

Aggiungete gradualmente utenti o sessioni client tramite script, mantenendo simile la combinazione di azioni tra un passaggio e l’altro. Una sequenza domestica utile potrebbe raddoppiare le sessioni attive partendo da una baseline ridotta, ma i numeri esatti sono meno importanti del fatto di modificare soltanto la concorrenza e mantenere costante la definizione del carico di lavoro.

Definite i limiti di latenza, errori e throughput prima del test e utilizzate percorsi realistici composti da più passaggi invece di sollecitare ripetutamente un singolo endpoint. Un carico di lavoro realistico per i test di carico di Immich dovrebbe combinare le azioni realmente eseguite nella vostra abitazione, invece di considerare richieste di accesso ripetute come indicatore della capacità di un server fotografico.

Mantenete ogni livello abbastanza a lungo da consentire l’assestamento delle cache, delle code, delle connessioni al database e della domanda di storage. Registrate sia il picco sia l’eventuale recupero del sistema dopo la rimozione del carico. Un server che sembra adeguato per un breve picco, ma lascia una coda di processi in crescita, ha già superato il livello sostenibile per quel carico di lavoro.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Individuate la prima risorsa che raggiunge la saturazione

Quando la latenza aumenta bruscamente, mettete in relazione il timestamp con il comportamento delle risorse. La saturazione della CPU durante la ricerca o il machine learning suggerisce una pressione computazionale; un’elevata latenza del disco con CPU moderatamente utilizzata indica un possibile problema del database o dello storage dei contenuti multimediali; collegamenti di rete saturi indicano limiti nel trasferimento o nell’accesso remoto; l’aumento delle attese del database o la pressione sulle connessioni indicano un problema a livello dati.

I processi in background possono modificare il risultato, perché la creazione delle miniature, la transcodifica, il machine learning, le scansioni, i backup o i cicli di nuovi tentativi possono consumare risorse anche quando nessuno sta navigando attivamente. Confrontate il test con le condizioni di carico in background di Immich mantenute sotto controllo, così da non scambiare i processi pianificati per un limite ridotto di utenti.

Non “risolvete” i problemi di capacità nascondendo gli errori con timeout client più lunghi. Modificate la risorsa limitante o la politica del carico di lavoro, ad esempio pianificando i processi pesanti, migliorando la posizione dello storage, riducendo le transcodifiche simultanee o aggiungendo capacità di calcolo; quindi riproducete il passaggio che ha causato l’errore per dimostrare che il collo di bottiglia si è spostato o è scomparso.

Stabilite un intervallo di capacità domestica pratico e ripetete il test

Definite la capacità pratica come la concorrenza massima testata alla quale tutti i percorsi utente richiesti restano entro i limiti di latenza ed errore stabiliti in precedenza, le code tornano verso la baseline dopo il test e l’host conserva sufficiente margine per il normale lavoro in background. Indicatela come un intervallo specifico per il carico di lavoro, non come un massimo valido per Immich in generale.

Ripetete almeno una volta il passaggio limite partendo da uno stato pulito e confrontabile, includendo le azioni che in precedenza avevano causato il degrado. Poi testate brevemente il passaggio successivo, quanto basta per confermare che il limite si presenti ancora nella stessa risorsa, senza portare il sistema verso una coda incontrollata o un evento di pressione sullo storage.

Ripetete lo stesso test dopo aggiornamenti importanti di Immich, spostamenti del database, modifiche allo storage, cambiamenti hardware o un aumento significativo delle dimensioni della libreria. Il vostro numero di utenti è una proprietà del sistema e del carico di lavoro attuali; conservare la procedura del test è più utile che conservare un vecchio conteggio degli utenti.