Vad cachar Home Assistant egentligen, och vilka upprepade förfrågningar går snabbare?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

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

”Home Assistant är snabbare andra gången” kan beskriva flera olika mekanismer. En webbläsare kan återanvända frontendresurser, en redan öppen instrumentpanel kan ta emot aktuell status via WebSocket i stället för att bygga om sidan, operativsystemet kan behålla databas- eller konfigurationssidor i minnet och en integration kan återanvända en etablerad anslutning.

Att kalla alla dessa effekter för ”Home Assistant-cachen” döljer var hastighetsökningen uppstår. Den användbara modellen är att namnge den upprepade begäran och sedan identifiera vilket lager som kan undvika arbete andra gången.

Webbläsarcachen snabbar upp frontendresurser

JavaScript, stilmallar, ikoner, anpassade kort och andra frontendresurser kan ligga kvar i en webbläsarcache, så att en upprepad sidladdning slipper hämta eller bygga om samma resurser från grunden.

Home Assistants aktuella webbläsarvägledning påpekar uttryckligen att användargränssnittet cachar mycket i webbläsaren för att bli snabbt. Samma cache kan bli inaktuell efter uppdateringar eller ändringar av anpassade kort, vilket är anledningen till att en hård uppdatering kan lösa ett gränssnitt som beter sig fel.

Den här cachen påverkar sidans start och rendering, inte hastigheten för fysisk enhetsstyrning. Att rensa den är ett frontendtest, inte en allmän återställning av serverprestandan.

En öppen instrumentpanel återanvänder en aktiv WebSocket-statusväg

När frontend är ansluten behöver den inte hämta hela smarthemstillståndet igen för varje ändring. Den tar emot uppdateringar och prenumerationer via WebSocket-API:t och uppdaterar de relevanta gränssnittskomponenterna.

Den aktuella frontendarkitekturen beskriver hur frontend tar emot kärnstatus genom ett delat hass-objekt och håller ytterligare prenumererade data synkroniserade via WebSockets. En väggmonterad surfplatta som förblir ansluten har därför en annan väg för upprepade begäranden än en telefon som öppnar instrumentpanelen från ett kallt läge varje morgon.

Tolka inte denna återanvändning som ett bevis på att många fler klienter skalas linjärt. Varje ytterligare klient kan fortfarande bidra med serialisering, prenumerationer, historikbegäranden och renderingsarbete på klientsidan.

Linux sidcache snabbar upp upprepade fil- och databasläsningar

Normala filsystemsläsningar går genom Linux sidcache. Nyligen använda databassidor, konfigurationsfiler och statiska resurser kan ligga kvar i minnet och undvika en ny fysisk lagringsläsning vid en upprepad begäran.

Den aktuella dokumentationen för Linuxkärnan förklarar att normala filläsningar fyller sidcachen så att efterföljande läsningar kan undvika dyrare åtkomst till lagringen. Det innebär att en upprepad historikfråga kan dra nytta av minnet även när Home Assistant inte har implementerat någon särskild cache på applikationsnivå för just den frågan.

Det är därför skillnader mellan SSD och HDD kan se mindre ut i ett varmt test än efter omstart, cacheutkastning eller med en mycket större arbetsmängd.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Varma data innebär inte att den underliggande frågan blev billigare

En historikbegäran kan fortfarande skanna eller indexera samma logiska datamängd, medan sidorna den behöver råkar finnas i minnet. En instrumentpanel kan fortfarande begära samma entiteter medan resurser och anslutningsstatus redan är tillgängliga.

Den relaterade benchmarkguiden från ZimaSpace om att skilja prestanda med varm cache från faktisk kapacitet visar den praktiska konsekvensen: cache är användbart, men ett kapacitetsanspråk måste klara realistiskt cachetryck och en ihållande arbetsbelastning.

En cacheträff tar bort en kostnad från en begäran. Den tar inte bort CPU-, minnes-, nätverks-, databas- eller integrationsarbete som hör till andra steg i flödet.

Olika upprepade begäranden värmer upp olika lager

Ladda om samma instrumentpanel: webbläsarresurser och klientens körmiljö kan vara varma.
Hålla en väggmonterad surfplatta öppen: WebSocket-status och prenumerationer förblir aktiva.
Upprepa samma historikintervall: databas- och filsystemssidor kan ligga kvar i minnet.
Anropa samma lokala tjänst: etablerade integrations- eller nätverksanslutningar kan redan finnas.
Öppna efter en omstart: flera av dessa lager kan vara kalla samtidigt.

Mät det lager som motsvarar användarens åtgärd i stället för att rensa alla cachar och kalla det ”vetenskapligt”.

Vanliga frågor

Gör det Home Assistant Core långsammare att rensa webbläsarcachen?

Det ändrar främst frontendens laddningsväg. Core kör fortfarande samma serverlogik, men webbläsaren kan behöva hämta och bygga om resurser igen, vilket gör den första laddningen av gränssnittet långsammare.

Är en varm historikfråga oanvändbar för benchmarking?

Nej. Varma frågor representerar ett verkligt driftläge. Misstaget är att behandla det varma resultatet som det enda kapacitetsresultatet, när minnestryck, omstart eller en större arbetsmängd kan ta bort samma cachefördel.