Come misurare le prestazioni di Immich senza confondere la cache con la capacità

La capacità di Immich dovrebbe essere misurata con carichi di lavoro ripetuti a freddo, a caldo e sostenuti, perché una singola esecuzione rapida con cache può nascondere il reale punto di saturazione del sistema.

Un home server può far sembrare estremamente veloce una timeline o un album dopo che le stesse miniature, le pagine del database e i dati dell’applicazione sono già stati utilizzati. Questo risultato dimostra che il percorso a caldo è efficiente, non che il sistema possa sostenere una libreria familiare più grande o un’attività simultanea maggiore. Un test di capacità utile deve controllare lo stato della cache, ampliare il working set, ripetere le esecuzioni e definire una condizione di arresto misurabile.

La velocità della cache non equivale alla capacità

La capacità descrive quanta attività rappresentativa un sistema Immich riesce a sostenere prima che latenza, code o errori diventino inaccettabili. La velocità della cache risponde a una domanda più circoscritta: con quale rapidità il sistema può ripetere un’attività dopo che dati utili o risorse generate sono già a portata di mano? Se un benchmark ripete lo stesso album o la stessa timeline, queste due domande possono sembrare identiche, anche se misurano condizioni operative diverse.

La differenza è facile da osservare nelle prestazioni web, dove i tempi della prima visualizzazione e delle visualizzazioni successive possono divergere perché le richieste successive riutilizzano risorse memorizzate nella cache. Immich offre ulteriori opportunità di funzionamento a caldo, perché possono essere riutilizzate miniature, anteprime, pagine del database, metadati del filesystem, cache del sistema operativo e risorse del client. Un’esecuzione ripetuta può quindi eliminare attività che una libreria in crescita o appena consultata deve ancora svolgere.

È per lo stesso motivo che un test di Home Assistant incentrato sulla cache può risultare fuorviante quando nel campione predominano richieste ripetute; la discussione di ZimaSpace sui livelli di cache per richieste ripetute si applica anche alla logica di misurazione in questo caso. Per Immich, registra le prestazioni a caldo, ma indicarle come un percorso separato invece di trattarle come la capacità generale del server.

Separa le esecuzioni a freddo, a caldo e a regime

Inizia definendo lo stato prima di avviare il cronometro. Un’esecuzione a freddo dovrebbe includere attività che non sono state appena ripetute, ad esempio l’apertura di un intervallo di date o di un insieme di risorse diverso, dopo che le cache hanno avuto meno opportunità di essere utili. Un’esecuzione a caldo ripete deliberatamente un percorso noto. Un’esecuzione a regime mantiene un’attività rappresentativa abbastanza a lungo da portare alla luce il lavoro in background, il riciclo delle risorse e le code che un breve picco di attività potrebbe non rivelare mai.

Anche la fase di riscaldamento può essere fuorviante. Percona descrive casi in cui un database sembra riscaldato mentre processi in background ritardati continuano a modificare le prestazioni, per cui il regime stabile arriva più tardi delle prime query rapide. In modo analogo, Immich può sovrapporre la navigazione in primo piano all’attività del database, all’elaborazione delle miniature, all’indicizzazione o ad altri processi in coda, a seconda di ciò che la libreria sta facendo in quel momento.

Per un test su home server, esegui ogni fase separatamente invece di calcolarne la media insieme alle altre. Indica se i processi in background sono inattivi o attivi, mantieni costanti il client e il percorso di rete e ripeti più volte la stessa fase. Se l’esecuzione a caldo è rapida, ma un’attività sostenuta aumenta gradualmente la latenza o la profondità delle code, il secondo risultato è il segnale migliore per pianificare la capacità.

Rendi il working set più grande della cache facilmente sfruttabile

Un benchmark che apre le stesse venti foto è solitamente troppo limitato per rispondere a una domanda sulla capacità di una libreria familiare. Il sistema operativo, il database, il client e lo stack di archiviazione possono mantenere un piccolo insieme di dati utilizzati di frequente vicino al processore, mentre nell’uso reale si passa rapidamente da mesi, persone, album, risultati di ricerca e video diversi. Il set di test dovrebbe quindi essere abbastanza grande e vario da fare in modo che non tutte le operazioni traggano vantaggio dagli stessi dati utilizzati di recente.

Le pratiche di benchmarking dei database rendono esplicita la distinzione: quando un test intende esaminare l’archiviazione o il comportamento a freddo, la cache residua può trasformare l’esercizio in un test delle prestazioni della cache. Non è necessario svuotare ogni livello di cache su un server Immich in produzione per ottenere informazioni utili, ma serve un carico di lavoro il cui working set sia più ampio di una singola schermata riutilizzata ripetutamente.

Scegli diversi intervalli di date, album, ricerche e tipi di risorse che rispecchino il normale utilizzo domestico, quindi alternali invece di insistere su una sola vista. Mantieni invariata la definizione del carico di lavoro nei confronti tra hardware o configurazioni. Se una modifica migliora soltanto un piccolo sottoinsieme ripetuto, mentre la navigazione più ampia continua a peggiorare sotto carico, ha migliorato il percorso a caldo senza spostare il limite di capacità utile.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Misura i percentili e ripeti il test

Una sola media può nascondere i momenti che gli utenti notano davvero. Se nove richieste sono rapide e la decima si blocca mentre si forma una coda o l’archiviazione è occupata, la media può comunque sembrare rispettabile. Registra almeno il comportamento mediano e un percentile della coda, come p95, quindi associa la latenza a throughput, numero di errori, arretrato dei processi, CPU, pressione sulla memoria e attività dell’archiviazione, così da contestualizzare il rallentamento.

L’analisi pratica dei benchmark consiglia di riportare p50, p95, p99 e la varianza invece di affidarsi a una singola esecuzione, soprattutto per i sistemi con stato, in cui l’espulsione della cache, la compattazione o l’attività in background possono comparire in un secondo momento. I test di Immich non richiedono una precisione da laboratorio, ma devono includere un numero sufficiente di ripetizioni per distinguere un limite riproducibile da un fortuito intervallo di quiete.

Esegui lo stesso scenario almeno diverse volte a ogni livello di carico e conserva le osservazioni grezze invece di mantenere soltanto il risultato migliore. Un’affermazione sulla capacità è più credibile quando il p95 rimane stabile tra le esecuzioni e il server svuota il lavoro in coda tra una finestra e l’altra. Se i risultati oscillano molto, esamina la variabile non controllata prima di dichiarare che più utenti, più foto o un hardware più veloce abbiano modificato il limite.

Usa un protocollo di capacità per Immich con una condizione di arresto

Inizia con un carico di lavoro rappresentativo di un singolo client e acquisisci una baseline dopo che il sistema ha raggiunto lo stato che intendi testare. Poi aumenta una variabile alla volta: più navigazione simultanea, caricamenti, ricerche o elaborazione in background, mantenendo fissi libreria, combinazione di client, percorso di rete e configurazione del server. A ogni passaggio, registra la latenza p50 e p95, le operazioni riuscite al minuto, gli errori, la crescita delle code e la principale risorsa del server che si sta avvicinando alla saturazione.

Questo approccio evita l’errore comune di trarre conclusioni da una singola esecuzione breve. Le linee guida sui test delle prestazioni mettono in guardia dalle conclusioni basate su una singola esecuzione, perché il riscaldamento, lo stato della cache, il lavoro in background e il normale rumore del sistema possono dominare un campione. Ripeti ogni livello di carico finché la tendenza non è abbastanza stabile da poter essere spiegata, non soltanto abbastanza comoda da essere citata.

Definisci una regola di arresto prima del test. Un criterio pratico per un laboratorio domestico è considerare saturata la configurazione corrente quando la latenza p95 rimane al di sopra di circa il doppio della baseline a vuoto per tre finestre di misurazione consecutive, oppure quando gli errori o l’arretrato dei processi continuano a crescere invece di ridursi; si tratta di un criterio di test, non di un limite di Immich. Il valore di capacità utile è l’ultimo livello di carico al di sotto di quella soglia, misurato con lo stesso protocollo a freddo, a caldo e a regime.