Wat cachet Home Assistant eigenlijk, en welke herhaalde verzoeken worden sneller?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

What Does Home Assistant Actually Cache, and Which Repeated Requests Get Faster? - Zima Store Online

“Home Assistant is de tweede keer sneller” kan verschillende mechanismen beschrijven. Een browser kan frontend-assets opnieuw gebruiken, een al geopend dashboard kan live status via WebSocket ontvangen in plaats van de pagina opnieuw op te bouwen, het besturingssysteem kan database- of configuratiepagina's in het geheugen houden en een integratie kan een bestaande verbinding hergebruiken.

Al die effecten “de Home Assistant-cache” noemen, verbergt waar de snelheidswinst optreedt. Het bruikbare model is om het herhaalde verzoek te benoemen en vervolgens vast te stellen welke laag bij de tweede uitvoering werk kan vermijden.

De browsercache versnelt frontend-assets

JavaScript, stijlen, pictogrammen, aangepaste kaarten en andere frontend-bronnen kunnen in een browsercache blijven staan, zodat een herhaalde paginalading voorkomt dat dezelfde assets opnieuw vanaf nul moeten worden gedownload of opgebouwd.

De huidige browserdocumentatie van Home Assistant vermeldt expliciet dat de gebruikersinterface veel zaken in de browser cachet om snel te blijven. Diezelfde cache kan verouderd raken na updates of wijzigingen aan aangepaste kaarten. Daarom kan een harde refresh een interface herstellen die zich verkeerd gedraagt.

Deze cache verandert het opstarten en weergeven van pagina's, niet de snelheid van fysieke apparaatbediening. De cache wissen is een frontendtest, geen algemene reset van de serverprestaties.

Een geopend dashboard hergebruikt een live WebSocket-statuspad

Zodra de frontend verbonden is, hoeft deze bij elke wijziging niet de volledige status van het slimme huis opnieuw op te vragen. De frontend ontvangt updates en abonnementen via de WebSocket-API en werkt de relevante interfacecomponenten bij.

De huidige frontendarchitectuur beschrijft hoe de frontend de kernstatus ontvangt via een gedeeld hass-object en aanvullende geabonneerde gegevens gesynchroniseerd houdt via WebSockets. Een wandtablet dat verbonden blijft, heeft daardoor een ander pad voor herhaalde verzoeken dan een telefoon die elke ochtend het dashboard volledig nieuw opent.

Vat dit hergebruik niet op als bewijs dat veel meer clients lineair zullen schalen. Elke extra client kan nog steeds serialisatie, abonnementen, geschiedenisverzoeken en rendering aan de clientzijde toevoegen.

De Linux-paginacache versnelt herhaalde bestands- en databaselezingen

Normale leesbewerkingen van het bestandssysteem lopen via de Linux-paginacache. Recent gebruikte databasepagina's, configuratiebestanden en statische assets kunnen in het geheugen blijven staan, waardoor een nieuwe fysieke opslaglezing bij een herhaald verzoek niet nodig is.

De huidige Linux-kerneldocumentatie legt uit dat normale bestandslezingen de paginacache vullen, zodat volgende lezingen duurdere opslagtoegang kunnen vermijden. Dat betekent dat een herhaalde geschiedenisquery voordeel kan hebben van het geheugen, ook wanneer Home Assistant voor die specifieke query geen speciale cache op applicatieniveau heeft geïmplementeerd.

Daarom kunnen verschillen tussen SSD en HDD kleiner lijken in een warme test dan na een herstart, het verwijderen van cachegegevens of een veel grotere werklast.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Warme gegevens betekenen niet dat de onderliggende query goedkoper is geworden

Een geschiedenisverzoek kan nog steeds dezelfde logische hoeveelheid gegevens scannen of indexeren, terwijl de benodigde pagina's toevallig al in het geheugen aanwezig zijn. Een dashboard kan nog steeds dezelfde entiteiten opvragen, terwijl assets en verbindingsstatus al beschikbaar zijn.

De gerelateerde ZimaSpace-benchmarkgids over het onderscheiden van prestaties met een warme cache van werkelijke capaciteit laat het praktische gevolg zien: cache is nuttig, maar een capaciteitsclaim moet standhouden onder realistische cachedruk en een aanhoudende werklast.

Een cache-hit verwijdert één kostenpost uit één verzoek. CPU-, geheugen-, netwerk-, database- of integratiewerk dat bij andere fasen van het pad hoort, verdwijnt daardoor niet.

Verschillende herhaalde verzoeken warmen verschillende lagen op

Hetzelfde dashboard opnieuw laden: browser-assets en de client-runtime kunnen al warm zijn.
Een wandtablet open houden: WebSocket-status en abonnementen blijven actief.
Dezelfde geschiedenisperiode opnieuw opvragen: database- en bestandssysteempagina's kunnen in het geheugen blijven.
Dezelfde lokale service aanroepen: bestaande integratie- of netwerkverbindingen kunnen al bestaan.
Openen na een herstart: meerdere van deze lagen kunnen tegelijk koud zijn.

Meet de laag die overeenkomt met de handeling van de gebruiker, in plaats van elke cache te wissen en dat “wetenschappelijk” te noemen.

Veelgestelde vragen

Maakt het wissen van de browsercache Home Assistant Core trager?

Het verandert vooral het laadpad van de frontend. Core voert nog steeds dezelfde serverlogica uit, maar de browser moet mogelijk assets opnieuw downloaden en opbouwen, waardoor de eerste interfacebelasting trager is.

Is een warme geschiedenisquery onbruikbaar voor benchmarking?

Nee. Warme queries vertegenwoordigen een realistische gebruiksomstandigheid. De fout is om het warme resultaat te behandelen als het enige capaciteitsresultaat, terwijl geheugendruk, een herstart of een grotere werklast hetzelfde cachevoordeel kan wegnemen.