Che cosa memorizza davvero nella cache Home Assistant e quali richieste ripetute diventano più veloci?

“Home Assistant è più veloce la seconda volta” può descrivere diversi meccanismi. Un browser può riutilizzare le risorse frontend, una dashboard già aperta può ricevere lo stato in tempo reale tramite WebSocket invece di ricostruire la pagina, il sistema operativo può mantenere in memoria le pagine del database o della configurazione e un’integrazione può riutilizzare una connessione già stabilita.

Chiamare tutti questi effetti “la cache di Home Assistant” nasconde il punto in cui si verifica l’accelerazione. Il modello utile consiste nel denominare la richiesta ripetuta e poi identificare il livello che può evitare del lavoro alla seconda esecuzione.

La cache del browser accelera le risorse frontend

JavaScript, stili, icone, schede personalizzate e altre risorse frontend possono rimanere nella cache del browser, così un caricamento ripetuto della pagina evita di scaricare o ricostruire da zero le stesse risorse.

Le attuali indicazioni di Home Assistant per i browser sottolineano esplicitamente che l’interfaccia utente memorizza molte cose nella cache del browser per essere più veloce. La stessa cache può diventare obsoleta dopo gli aggiornamenti o le modifiche alle schede personalizzate, motivo per cui un aggiornamento forzato può risolvere un’interfaccia che non funziona correttamente.

Questa cache modifica l’avvio e il rendering della pagina, non la velocità di controllo fisico dei dispositivi. Svuotarla è un test del frontend, non un ripristino generale delle prestazioni del server.

Una dashboard aperta riutilizza un canale di stato WebSocket attivo

Una volta connesso il frontend, non è necessario recuperare nuovamente l’intero stato della smart home a ogni modifica. Riceve aggiornamenti e sottoscrizioni tramite l’API WebSocket e aggiorna i componenti dell’interfaccia interessati.

L’architettura frontend attuale descrive come il frontend riceva lo stato principale tramite un oggetto hass condiviso e mantenga sincronizzati altri dati sottoscritti tramite WebSocket. Un tablet a parete che rimane connesso segue quindi un percorso di richieste ripetute diverso da quello di un telefono che apre la dashboard a freddo ogni mattina.

Non interpretate questo riutilizzo come una prova che molti più client possano scalare linearmente. Ogni client aggiuntivo può comunque aumentare il lavoro di serializzazione, gestione delle sottoscrizioni, richieste di cronologia e rendering lato client.

La cache delle pagine di Linux accelera le letture ripetute di file e database

Le normali letture del filesystem passano attraverso la cache delle pagine di Linux. Le pagine del database, i file di configurazione e le risorse statiche usati di recente possono rimanere in memoria ed evitare una nuova lettura fisica dello spazio di archiviazione nelle richieste ripetute.

La documentazione attuale del kernel Linux spiega che le normali letture dei file popolano la cache delle pagine, così le letture successive possono evitare un accesso più costoso allo spazio di archiviazione. Ciò significa che una query ripetuta della cronologia può beneficiare della memoria anche quando Home Assistant non ha implementato una cache speciale a livello applicativo per quella query specifica.

Ecco perché le differenze tra SSD e HDD possono apparire più contenute in un test a caldo rispetto a un test eseguito dopo un riavvio, l’espulsione della cache o con un working set molto più grande.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

I dati già in memoria non significano che la query sottostante sia diventata meno costosa

Una richiesta della cronologia può comunque analizzare o indicizzare la stessa quantità logica di dati, mentre le pagine necessarie si trovano già in memoria. Una dashboard può continuare a richiedere le stesse entità mentre le risorse e lo stato della connessione sono già disponibili.

La guida correlata di ZimaSpace sui benchmark, dedicata a separare le prestazioni con cache a caldo dalla capacità effettiva, mostra la conseguenza operativa: la cache è utile, ma un’affermazione sulla capacità deve resistere a una pressione realistica sulla cache e a un carico di lavoro prolungato.

Un riscontro positivo della cache elimina un costo da una richiesta. Non elimina il lavoro di CPU, memoria, rete, database o integrazione appartenente alle altre fasi del percorso.

Richieste ripetute diverse riscaldano livelli diversi

• Ricaricare la stessa dashboard: le risorse del browser e il runtime client possono essere già in memoria.
• Tenere aperto un tablet a parete: lo stato WebSocket e le sottoscrizioni rimangono attivi.
• Ripetere lo stesso intervallo della cronologia: le pagine del database e del filesystem possono rimanere in memoria.
• Chiamare lo stesso servizio locale: le connessioni di integrazione o di rete già stabilite potrebbero esistere ancora.
• Aprire dopo un riavvio: diversi livelli possono trovarsi contemporaneamente a freddo.

Misurate il livello corrispondente all’azione dell’utente invece di svuotare ogni cache e chiamare il risultato “scientifico”.

Domande frequenti

Svuotare la cache del browser rende più lento Home Assistant Core?

Modifica principalmente il percorso di caricamento del frontend. Core continua a eseguire la stessa logica del server, ma il browser potrebbe dover scaricare e ricostruire nuovamente le risorse, rendendo più lento il primo caricamento dell’interfaccia.

Una query della cronologia a caldo è inutile per i benchmark?

No. Le query a caldo rappresentano una condizione operativa reale. L’errore consiste nel considerare il risultato a caldo come l’unico indicatore della capacità, quando la pressione sulla memoria, un riavvio o un working set più grande possono eliminare lo stesso vantaggio della cache.