Perché Immich sembra meno reattivo su client diversi?

Immich può sembrare più lento su un client perché il rendering lato client, la decodifica delle immagini, lo stato della cache e il percorso di rete aggiungono lavoro dopo la risposta del server.

Una famiglia può consultare la stessa libreria da un browser desktop, un telefono datato e un tablet, mentre il server Immich, lo spazio di archiviazione e il database rimangono invariati. Un dispositivo può comunque aprire più tardi le cronologie o le anteprime perché la richiesta end-to-end comprende attività che avvengono al di fuori del server. Il confronto utile è quindi tra il tempo di risposta del server e il tempo aggiuntivo che ogni client impiega per ricevere, decodificare, memorizzare nella cache e visualizzare il risultato.

Il client modifica il lavoro successivo alla risposta di Immich

Una richiesta Immich non termina quando il server ha preparato il JSON, l'URL di una miniatura o una risposta contenente un'immagine. Il client deve ancora elaborare la risposta, aggiornare l'interfaccia, programmare il rendering e reagire all'input dell'utente. Un server veloce può quindi coesistere con un client che sembra lento quando il dispositivo o il browser impiega più tempo a trasformare i dati restituiti in una schermata visibile e interattiva.

Questa distinzione è particolarmente importante nei browser, dove JavaScript, gestione degli eventi, calcolo degli stili, layout e gran parte del disegno competono per il lavoro sul thread principale. Se un telefono datato o un browser occupato mantiene impegnato quel thread più a lungo, i tocchi e lo scorrimento possono rallentare anche se l'API di Immich ha completato la richiesta più o meno nello stesso momento di un desktop più veloce.

Per questo confrontare soltanto la CPU del server o la latenza del database non restituisce il quadro completo dell'esperienza. La discussione di ZimaSpace sui client nativi e browser mostra lo stesso principio dei sistemi: un backend può alimentare percorsi di esecuzione diversi lato client. Per Immich, la prima domanda diagnostica è se il ritardo si verifica prima dell'arrivo della risposta o dopo che il client ha iniziato a elaborarla.

Il rendering delle immagini può far sembrare lente risposte rapide

La consultazione delle foto rende più evidente la differenza tra client, perché una galleria non è composta soltanto da testo e metadati API. Un client può richiedere molte miniature o un'anteprima più grande, conservarne alcune in memoria, decodificare dati immagine compressi, ridimensionarli per l'area visibile e comporre diverse immagini mentre l'utente continua a scorrere. La quantità e la tempistica di questo lavoro locale possono variare notevolmente tra dispositivi anche quando richiedono lo stesso contenuto Immich.

I formati compressi come JPEG e WebP devono passare attraverso la decodifica delle immagini prima che i pixel possano essere visualizzati. CPU più veloci, decoder meglio ottimizzati, maggiore memoria disponibile e motori del browser diversi possono ridurre questa fase. Su un client meno potente, la rete può terminare per prima, mentre la decodifica e il disegno diventano la fase per cui l'utente aspetta davvero.

La conseguenza pratica è che un'anteprima più grande o più nitida non è gratuita solo perché il server può generarla rapidamente. Le immagini a risoluzione più elevata richiedono più memoria per i pixel decodificati e più lavoro per essere ridimensionate e disegnate. Se un client diventa lento soprattutto durante l'apertura delle anteprime complete o lo scorrimento rapido di cronologie dense, mentre le schermate con semplici metadati rimangono reattive, il percorso di rendering delle immagini è una spiegazione più probabile di un limite di capacità generale del server.

Lo stato della cache influisce sulla velocità delle visite successive

Un client che ha già consultato un album può riutilizzare miniature, script, metadati o risorse decodificate che un client nuovo deve ancora ottenere ed elaborare. Questo rende più breve il secondo passaggio, ma non significa che il server abbia improvvisamente acquisito capacità. Significa che una parte del percorso della richiesta è scomparsa perché il client è partito da uno stato più caldo rispetto alla prima consultazione.

Studi reali sui browser mostrano che i tassi di utilizzo della cache variano tra browser, versioni, dispositivi e momenti diversi. Le percentuali specifiche di Facebook non sono un benchmark di Immich, ma il meccanismo è rilevante: due client possono raggiungere lo stesso server con cronologie locali della cache differenti. Un browser desktop con cache già popolata può quindi sembrare molto più reattivo di un'app per telefono appena installata senza dimostrare che uno dei due client sia intrinsecamente più veloce.

La cache può inoltre rendere fuorvianti i test prima-e-dopo. Aggiornare più volte lo stesso album può eliminare il lavoro di download ed elaborazione dalle esecuzioni successive, quindi l'esecuzione più veloce spesso misura il riutilizzo anziché un carico familiare rappresentativo. Se l'obiettivo è confrontare i client, registra sia un percorso a cache fredda o appena aperto sia un percorso ripetuto; la differenza tra i due è di per sé un'indicazione utile di quanto ogni client dipenda dal riutilizzo locale.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Quando le differenze tra client non spiegano più il ritardo

Le differenze tra client smettono di essere la spiegazione principale quando diversi client altrimenti differenti rallentano contemporaneamente sotto lo stesso carico. Se un browser desktop, un telefono e un tablet attendono tutti più a lungo i dati della cronologia o le risposte delle anteprime mentre aumentano l'utilizzo della CPU del server, la latenza dello spazio di archiviazione, l'attività del database o l'utilizzo della rete, l'infrastruttura condivisa diventa un limite alla reattività più plausibile rispetto a una singola implementazione client.

La temporizzazione end-to-end deve includere più del componente che sembra più semplice da misurare. Un'analisi della latenza di Datadog mostra che la latenza di andata e ritorno può includere il trasferimento di rete, i proxy, i pool di connessioni e la decodifica dell'applicazione al di fuori del database stesso. Lo stesso principio si applica a Immich: un valore sano del database non può escludere un ritardo in un altro punto tra l'inizio della richiesta e il risultato visualizzato.

Un utile test di confine è la simmetria. Se soltanto un client è lento mentre un altro sulla stessa LAN e con lo stesso album rimane veloce, l'esecuzione del client, la cache o la rete locale meritano maggiore attenzione. Se tutti i client superano la stessa soglia di latenza più o meno nello stesso momento, soprattutto durante importazioni, generazione di miniature, backup o altre attività del sistema, la spiegazione si è spostata dalla variabilità dei client verso un vincolo condiviso del server, dello spazio di archiviazione o della rete.

Usa un test controllato tra client per individuare il confine

Scegli un album rappresentativo e mantieni costanti la versione del server, la posizione nella rete, l'account, il set di immagini e lo stato dei processi in background. Testa ogni client uno alla volta e registra tre tempi osservabili: il caricamento iniziale della cronologia, l'apertura della stessa anteprima di grandi dimensioni e uno scorrimento rapido su un intervallo fisso di foto. Nota anche se il server mostra un picco di risorse durante ogni esecuzione, perché un confronto tra client non è valido se il carico del backend cambia tra un campione e l'altro.

Esegui il test su ogni client una volta partendo da uno stato deliberatamente freddo e poi ripetilo subito dopo. I test delle prestazioni distinguono comunemente i risultati della prima visualizzazione e delle visualizzazioni successive perché le cache popolate eliminano lavoro dalle richieste seguenti. Per Immich, la differenza tra freddo e caldo mostra quanto il riutilizzo modifichi l'esperienza, mentre la differenza tra client nelle stesse condizioni di cache evidenzia variazioni più probabilmente locali al dispositivo o all'applicazione.

Considera una differenza legata al client solo quando si ripete in almeno tre esecuzioni e il client più veloce rimane tale mentre le condizioni del server e della rete restano comparabili. Se tutti i client peggiorano insieme, smetti di ottimizzare il client ed esamina il percorso comune. Se divergono soltanto le azioni che coinvolgono molte immagini, concentrati sulla decodifica e sul rendering. Se la differenza compare soltanto nella prima esecuzione, lo stato della cache, non la capacità sostenibile del server, è la conclusione più plausibile.