Was cached Home Assistant tatsächlich, und welche wiederholten Anfragen werden schneller?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

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

„Home Assistant ist beim zweiten Mal schneller“ kann mehrere verschiedene Mechanismen beschreiben. Ein Browser kann Frontend-Ressourcen wiederverwenden, ein bereits geöffnetes Dashboard kann den Live-Zustand per WebSocket empfangen, statt die Seite neu aufzubauen, das Betriebssystem kann Datenbank- oder Konfigurationsseiten im Speicher behalten, und eine Integration kann eine bestehende Verbindung wiederverwenden.

All diese Effekte als „den Home-Assistant-Cache“ zu bezeichnen, verschleiert, wo der Geschwindigkeitsvorteil entsteht. Das nützliche Modell besteht darin, die wiederholte Anfrage zu benennen und anschließend zu ermitteln, welche Ebene beim zweiten Durchlauf Arbeit vermeiden kann.

Der Browser-Cache beschleunigt Frontend-Ressourcen

JavaScript, Styles, Symbole, benutzerdefinierte Karten und andere Frontend-Ressourcen können im Browser-Cache verbleiben, sodass ein wiederholtes Laden der Seite das erneute Herunterladen oder Aufbauen derselben Ressourcen von Grund auf vermeidet.

Die aktuellen Browser-Hinweise von Home Assistant weisen ausdrücklich darauf hin, dass die Benutzeroberfläche viele Dinge im Browser zwischenspeichert, damit sie schnell ist. Derselbe Cache kann nach Updates oder Änderungen an benutzerdefinierten Karten veraltet sein. Deshalb kann eine vollständige Aktualisierung eine fehlerhaft funktionierende Benutzeroberfläche beheben.

Dieser Cache verändert den Start und die Darstellung der Seite, nicht die Geschwindigkeit der physischen Gerätesteuerung. Ihn zu leeren, ist ein Frontend-Test und kein allgemeines Zurücksetzen der Serverleistung.

Ein geöffnetes Dashboard verwendet einen aktiven WebSocket-Zustandspfad wieder

Sobald das Frontend verbunden ist, muss es den gesamten Smart-Home-Zustand nicht für jede Änderung erneut abrufen. Es empfängt Aktualisierungen und Abonnements über die WebSocket-API und aktualisiert die jeweils relevanten Komponenten der Benutzeroberfläche.

Die aktuelle Frontend-Architektur beschreibt, wie das Frontend den Kernzustand über ein gemeinsames hass-Objekt empfängt und zusätzliche abonnierte Daten über WebSockets synchron hält. Ein Wandtablet, das dauerhaft verbunden bleibt, verwendet daher einen anderen Pfad für wiederholte Anfragen als ein Smartphone, das jeden Morgen das Dashboard vollständig neu öffnet.

Diese Wiederverwendung ist jedoch kein Beleg dafür, dass sich deutlich mehr Clients linear skalieren lassen. Jeder zusätzliche Client kann weiterhin Serialisierungs-, Abonnement-, Verlaufsabfrage- und clientseitige Renderarbeit verursachen.

Der Linux-Seitencache beschleunigt wiederholte Datei- und Datenbankzugriffe

Normale Dateisystemlesevorgänge laufen über den Linux-Seitencache. Kürzlich verwendete Datenbankseiten, Konfigurationsdateien und statische Ressourcen können im Speicher verbleiben und bei einer wiederholten Anfrage einen weiteren physischen Speicherzugriff vermeiden.

Die aktuelle Dokumentation des Linux-Kernels erklärt, dass normale Dateilesevorgänge den Seitencache füllen, sodass nachfolgende Lesevorgänge auf einen kostspieligeren Speicherzugriff verzichten können. Das bedeutet, dass eine wiederholte Verlaufsabfrage vom Speicher profitieren kann, selbst wenn Home Assistant für genau diese Abfrage keinen speziellen Anwendungscache implementiert hat.

Deshalb können sich die Unterschiede zwischen SSD und HDD in einem aufgewärmten Test kleiner darstellen als nach einem Neustart, dem Verdrängen von Cache-Inhalten oder bei einem deutlich größeren Arbeitssatz.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Warme Daten bedeuten nicht, dass die zugrunde liegende Abfrage günstiger geworden ist

Eine Verlaufsanfrage kann weiterhin dieselbe logische Datenmenge durchsuchen oder indizieren, während die benötigten Seiten zufällig bereits im Speicher liegen. Ein Dashboard kann weiterhin dieselben Entitäten anfordern, während Ressourcen und Verbindungszustand bereits verfügbar sind.

Der zugehörige Benchmark-Leitfaden von ZimaSpace zum Trennen der Leistung bei warmem Cache von der tatsächlichen Kapazität zeigt die praktische Konsequenz: Cache ist nützlich, aber eine Kapazitätsaussage muss realistische Cache-Belastung und eine anhaltende Arbeitslast überstehen.

Ein Cache-Treffer beseitigt einen Kostenfaktor bei einer Anfrage. Er beseitigt nicht die CPU-, Speicher-, Netzwerk-, Datenbank- oder Integrationsarbeit, die zu anderen Phasen des Ablaufs gehört.

Verschiedene wiederholte Anfragen wärmen unterschiedliche Ebenen auf

Dasselbe Dashboard neu laden: Browser-Ressourcen und die Client-Laufzeit können bereits geladen sein.
Ein Wandtablet geöffnet lassen: WebSocket-Zustand und Abonnements bleiben aktiv.
Denselben Verlaufszeitraum wiederholen: Datenbank- und Dateisystemseiten können im Speicher verbleiben.
Denselben lokalen Dienst aufrufen: Bereits eingerichtete Integrations- oder Netzwerkverbindungen können noch bestehen.
Nach einem Neustart öffnen: Mehrere dieser Ebenen können gleichzeitig kalt sein.

Messen Sie die Ebene, die der Aktion des Benutzers entspricht, statt jeden Cache zu leeren und das „wissenschaftlich“ zu nennen.

FAQ

Wird Home Assistant Core durch das Leeren des Browser-Caches langsamer?

Es verändert hauptsächlich den Ladepfad des Frontends. Core führt weiterhin dieselbe Serverlogik aus, aber der Browser muss Ressourcen möglicherweise erneut herunterladen und aufbauen, wodurch das erste Laden der Benutzeroberfläche länger dauert.

Ist eine warme Verlaufsabfrage für Benchmarks nutzlos?

Nein. Warme Abfragen stellen eine reale Betriebsbedingung dar. Der Fehler besteht darin, das warme Ergebnis als einziges Kapazitätsergebnis zu betrachten, obwohl Speicherdruck, ein Neustart oder ein größerer Arbeitssatz denselben Cache-Vorteil beseitigen können.