Un benchmark ripetibile di Immich fissa il gruppo di contenuti multimediali, il percorso del client, lo stato della cache, la sovrapposizione delle attività in background e l’endpoint misurato prima di modificare una sola variabile.
Senza questi controlli, un secondo avvio più veloce può riflettere dati già in cache anziché hardware migliore, mentre un test in condizioni di inattività può nascondere la contesa durante l’importazione. Un benchmark utile per un home server riproduce le reali esigenze domestiche di consultazione, caricamento, ricerca e ripristino nella stessa sequenza.
Definisci i risultati per l’utente prima di raccogliere le metriche
Inizia da risultati osservabili, come l’accettazione del caricamento, il tempo necessario affinché una nuova foto diventi ricercabile, il completamento delle miniature nella timeline, l’apertura dell’originale, l’avvio di un video o il ripristino di una libreria utilizzabile. L’utilizzo della CPU e il throughput del disco spiegano questi risultati, ma non sostituiscono il risultato percepito dall’utente.
L’articolo di ZimaSpace sul percorso dei dati di Immich distingue l’accettazione del caricamento, la disponibilità per l’elaborazione, la selezione nei risultati di ricerca e la distribuzione dei contenuti multimediali. Questa struttura è utile perché un benchmark deve misurare un solo endpoint, invece di combinare diverse fasi dipendenti in un totale fuorviante.
Seleziona due endpoint interattivi e uno in background. Assegna a ciascuno un obiettivo di superamento del test e registra la latenza mediana e quella della coda lenta, oppure il tasso di completamento. Un benchmark con molti punteggi non correlati diventa difficile da interpretare; un insieme ristretto, legato a una decisione specifica, mantiene il risultato concreto e utilizzabile.
Blocca il dataset, il percorso del client e lo stato iniziale
Usa le stesse foto e gli stessi video rappresentativi in ogni esecuzione, includendo formati e dimensioni che riflettano la libreria familiare. Mantieni fissi l’account, il dispositivo client, il percorso di rete, la versione di Immich e le impostazioni dei derivati. Anche una cache del browser o un percorso Wi-Fi diversi possono sovrastare la differenza di configurazione che stai testando.
Un articolo sul benchmark della ricerca vettoriale sottolinea l’importanza di workload ripetibili per la generazione degli embedding, l’inserimento e il recupero nello studio delle prestazioni di ricerca di PostgreSQL. Immich è un’applicazione più ampia, ma il principio sperimentale è applicabile anche qui: servono input controllati e operazioni di recupero definite prima che le differenze nei tempi possano sostenere una conclusione.
Crea un manifest del dataset contenente checksum dei file, conteggi, totali in byte, formati delle foto, durate dei video e risultati di ricerca attesi. Aggiungi una checklist iniziale per i servizi riavviati, le attività di riscaldamento, i processi in coda e le applicazioni concorrenti. Se la checklist cambia, contrassegna l’esecuzione come non comparabile invece di calcolarne la media.
Esegui fasi a freddo, a caldo e prolungate
La fase a freddo rivela il costo dell’inizializzazione e del primo accesso. La fase a caldo mostra il riutilizzo durante la ripetizione immediata. La fase prolungata combina interazioni ripetute con un’importazione rappresentativa o una coda in background sufficientemente lunga da far emergere la limitazione termica, la pressione sulla memoria, le code di archiviazione e la competizione per le risorse.
Un report della community descrive una prima ricerca intelligente che richiede circa cinque secondi e una ripetizione immediata di circa mezzo secondo, mentre cambia la memoria del modello. Questi valori non sono uno standard di benchmark; dimostrano perché calcolare la media tra richieste a freddo e a caldo nasconde la transizione che il test deve spiegare.
Esegui ogni fase almeno tre volte, conservando i timestamp grezzi e le tracce delle risorse. Mantieni la mediana e una misura della coda lenta per il lavoro interattivo, oltre agli elementi in coda al minuto per il lavoro in background. Interrompi l’esecuzione se errori, attività intensa di swap o limiti termici invalidano la condizione stabile prevista.
Usa una scheda di esecuzione con una sola variabile
Scrivi l’ipotesi prima dell’esecuzione: modificare la posizione del database, la concorrenza dei worker, il limite di memoria, il percorso di rete o l’acceleratore dovrebbe migliorare un endpoint specifico attraverso un meccanismo dichiarato. Mantieni tutto il resto invariato. Questo impedisce che un aggiornamento con modifiche multiple produca un risultato più veloce senza una causa dimostrabile.
Un’analisi generale dei colli di bottiglia spiega che i limiti di CPU, RAM, archiviazione e rete producono diversi schemi di utilizzo ed effetti sull’utente. Applicata a Immich, questa metrica di supporto dovrebbe variare in modo coerente con l’endpoint; il grafico più intenso non è automaticamente quello del componente limitante.
Registra i risultati di riferimento e quelli modificati per le fasi a freddo, a caldo e prolungate, quindi indica superato, non superato o inconcludente. Rifiuta i miglioramenti che scompaiono nelle ripetizioni o causano errori, temperature instabili, perdita dei progressi in coda o un ripristino più lungo. Conserva il manifest e la scheda di esecuzione affinché una versione futura possa essere confrontata in modo corretto.
Hub Tecnologico e AI
Altro da leggere

Perché Immich rielabora i dati esistenti dopo un aggiornamento?
Immich potrebbe rielaborare gli asset quando un aggiornamento rende non più validi derivati, metadati, modelli o lo stato dei processi precedenti; un’elaborazione ripetuta e...

Quali dipendenze determinano più spesso il reale limite delle prestazioni di Immich?
Immich è limitato dalla dipendenza più lenta di ogni percorso misurato, quindi caricamento, ricerca, navigazione e riproduzione possono avere limiti diversi.

Rete di Immich: come rilevamento, DNS e routing garantiscono la raggiungibilità
Immich è raggiungibile solo quando la selezione dell’endpoint, il DNS, il routing, il NAT o la gestione del proxy, il TLS e la risposta...

