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

Un test rapido e “caldo” di Home Assistant non dimostra una capacità residua; potrebbe dimostrare soltanto che le cache del browser, del database, del filesystem o dell’applicazione sono già popolate.

La capacità è la quantità di lavoro sostenuto che un sistema riesce a completare entro un obiettivo di latenza e correttezza, mentre la cache modifica il costo del lavoro ripetuto. Una dashboard che si apre rapidamente alla seconda visita, una query della cronologia accelerata dalle pagine in cache o un riavvio seguito da una singola automazione fluida possono essere osservazioni utili senza mostrare il limite massimo del carico. Misura separatamente le fasi a freddo, a caldo, a regime e di saturazione.

Separa innanzitutto gli effetti della cache dal carico di lavoro da dimensionare

I diversi percorsi di Home Assistant utilizzano cache differenti. I browser conservano le risorse del frontend; il sistema operativo memorizza nella cache le pagine del filesystem; SQLite o un altro database beneficia delle pagine lette di recente; le integrazioni possono mantenere connessioni o lo stato dei dispositivi; anche DNS e TLS possono essere riutilizzati. Un singolo benchmark “a caldo” può includere contemporaneamente diversi di questi effetti.

Una guida della community di Home Assistant sulle prestazioni del Recorder spiega come un database di grandi dimensioni generi più lavoro di lettura, scrittura e indicizzazione, mostrando che il carico del database cambia in base allo stato conservato, non soltanto alla velocità della CPU. Una cache delle pagine a caldo può nascondere parte di questo costo di lettura finché il working set non supera la memoria disponibile o un altro carico non lo espelle.

Definisci la domanda sulla capacità prima di eseguire il test: avvio della dashboard, query della cronologia, latenza delle automazioni, eventi al secondo, client simultanei, sovrapposizione dei backup o concorrenza dei servizi sull’intero host. Poi elenca le cache che possono ridurre il costo di quell’operazione specifica. Non svuotare indiscriminatamente tutte le cache; crea una condizione a freddo controllata e una condizione a caldo realistica, in modo da poterle misurare entrambe.

Usa esecuzioni a freddo e a caldo per delimitare i due estremi utili

Un’esecuzione a freddo mostra come si comporta il sistema quando dati o risorse non sono residenti, mentre un’esecuzione a caldo mostra il percorso di riutilizzo costante che gli utenti sperimentano spesso. Nessuna delle due condizioni è universalmente “reale”. Un telefono aperto una volta ogni mattina può essere più vicino al comportamento a freddo del frontend, mentre un tablet a parete o un database molto utilizzato può funzionare a caldo per gran parte della giornata.

Le note sui benchmark dello storage evidenziano che due esecuzioni consecutive possono differire semplicemente perché la prima riscalda la cache del filesystem; per questo è necessario identificare le condizioni della cache a freddo e a caldo anziché mescolarle. Lo stesso principio vale per i test della cronologia e delle risorse di Home Assistant: una seconda esecuzione rapida dimostra il riutilizzo, non prova di per sé una maggiore capacità del server.

Registra entrambe le distribuzioni, non soltanto il risultato migliore. Usa dati, client, rete e configurazione della dashboard identici. Se i risultati a caldo sono eccellenti ma quelli a freddo superano la scadenza prevista per la casa, il sistema può essere accettabile per client sempre aperti ma inadeguato per riavvii, ripristini o accessi mobili poco frequenti. Le affermazioni sulla capacità devono specificare a quale condizione si riferiscono.

La capacità emerge quando il lavoro ripetuto smette di scalare linearmente

Per misurare la capacità, aumenta una sola variabile del carico mantenendo costanti le altre: frequenza degli eventi, client delle dashboard, concorrenza delle query della cronologia, frequenza di scrittura del database o carico dei servizi vicini. Un’analisi reale di una dashboard di Home Assistant mostra come il carico continuo degli aggiornamenti WebSocket possa diventare evidente quando il client rimane indietro, rendendo le code e il comportamento della coda più informativi di un singolo picco con dati in cache. Osserva questi segnali insieme all’utilizzo di CPU, memoria, storage e rete.

ZimaSpace mostra un meccanismo di saturazione analogo nella contesa delle code dello storage condiviso: il throughput può rimanere elevato mentre la latenza della coda interattiva cresce dopo che il lavoro pendente supera il parallelismo utile. Anche la capacità di Home Assistant richiede condizioni di arresto attente alla latenza.

La regola fondamentale contro il marketing è che una maggiore quantità di CPU libera non garantisce una maggiore capacità dell’intero sistema. Un’automazione può attendere una radio, lo storage può essere saturo mentre la CPU è inattiva e un client mobile può eseguire il rendering lentamente dopo che il server ha risposto. La capacità appartiene all’intero percorso testato e alle condizioni mantenute costanti, non a una singola percentuale di utilizzo.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifica l’espulsione della cache e i servizi vicini prima di dichiarare un margine disponibile

Un home server non esegue Home Assistant nel vuoto. Backup, scansioni multimediali, processi di IA, registrazioni delle telecamere, database e container possono espellere pagine utili dalla cache o creare pressione concorrente su storage e memoria. Un benchmark eseguito su un host altrimenti vuoto può quindi riportare un working set a caldo che l’ambiente di produzione non riesce a mantenere residente durante il picco reale della casa.

Un caso di ottimizzazione del Recorder del 2026 offre un esempio pratico di riduzione del volume di scrittura dello storico, così che il database richieda meno I/O e un working set residente più contenuto. Questo modifica il reale limite di capacità invece di far sembrare semplicemente veloce una seconda query.

Ripeti il test a regime mentre sono in esecuzione i normali carichi di backup, telecamere o container. Se la latenza rimane entro l’obiettivo e il comportamento dei riscontri della cache resta stabile, il risultato a caldo è più credibile. Se le prestazioni crollano solo dopo che un altro servizio espelle la cache o riempie le code, l’host dispone di un margine operativo in produzione inferiore a quello suggerito dal benchmark isolato di Home Assistant.

Pubblica un risultato sulla capacità insieme alle relative condizioni

Un risultato utile specifica la versione di Home Assistant, l’hardware, lo storage, il database, il numero di entità, la conservazione dei dati, il tipo di client, la dashboard, il percorso di rete, la condizione a caldo o a freddo, i carichi in background, la frequenza di input, la durata del test e la soglia di accettazione. Senza questi dettagli, “Home Assistant risponde in 100 ms” non può essere confrontato né riprodotto.

Un’analisi indipendente della concorrenza in Home Assistant spiega come il ciclo di eventi asyncio pianifichi le attività delle automazioni e come le attese I/O possano sospendere tali attività. Quando il carico testato è fortemente basato sulle automazioni, includi la reattività del ciclo di eventi e il comportamento bloccante, invece di presumere che il solo utilizzo di storage o CPU descriva la capacità.

Definisci il sistema capace solo quando la peggiore sovrapposizione normale resta in esecuzione abbastanza a lungo da raggiungere il regime, la latenza di coda rimane entro l’obiettivo, le code non continuano a crescere e le prove ripetute producono risultati simili. Considera la cache a caldo come una condizione operativa, non come un moltiplicatore che puoi presumere resterà disponibile man mano che la casa e l’host accumulano altri servizi.

Domande frequenti

Devo riavviare Home Assistant prima di ogni benchmark?

No. Un riavvio può creare uno scenario di avvio a freddo, ma modifica anche molte variabili contemporaneamente. Usalo intenzionalmente per testare l’avvio, poi esegui test separati a caldo e a regime senza riavviare.

L’esecuzione più rapida è la stima migliore della capacità?

No. L’esecuzione più rapida mostra di solito condizioni favorevoli di cache e pianificazione. Le decisioni sulla capacità dovrebbero basarsi su distribuzioni ripetibili e sulla latenza di coda sotto carico sostenuto, perché gli utenti notano le esecuzioni lente quando il sistema è vicino alla saturazione.

Elevati tassi di riscontro della cache possono essere considerati negativi?

No. Il riutilizzo è desiderabile. L’errore consiste nel presumere che i dati memorizzati nella cache resteranno sempre residenti mentre crescono il working set, il numero di entità, lo storico e i servizi vicini. Misura cosa accade quando il carico non rientra più comodamente nello stesso ingombro della cache.