Så mäter du prestandan hos Home Assistant utan att förväxla cache med kapacitet

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.

How to Measure Home Assistant Performance Without Mistaking Cache for Capacity - Zima Store Online

Ett snabbt uppvärmt test av Home Assistant bevisar inte ledig kapacitet; det kan bara visa att webbläsarens, databasens, filsystemets eller programmets cache redan är fyllda.

Kapacitet är den mängd kontinuerligt arbete som ett system kan slutföra inom ett mål för fördröjning och korrekthet, medan cache ändrar kostnaden för upprepat arbete. En instrumentpanel som öppnas snabbt vid det andra besöket, en historikfråga som snabbas upp av cachade sidor eller en omstart följd av en enda smidig automatisering kan alla vara användbara observationer utan att visa arbetsbelastningens tak. Mät kalla, varma, stabila och mättade faser separat.

Separera först cacheeffekter från den arbetsbelastning du vill dimensionera

Olika vägar i Home Assistant har olika cacheminnen. Webbläsare behåller frontendresurser; operativsystemet cachar filsystemssidor; SQLite eller en annan databas drar nytta av nyligen lästa sidor; integrationer kan behålla anslutningar eller enhetsstatus; även DNS och TLS kan återanvändas. Ett enda ”varmt” riktmärke kan innehålla flera av dessa effekter samtidigt.

En guide från Home Assistant-communityn om Recorder-prestanda förklarar hur en stor databas skapar mer läs-, skriv- och indexarbete, vilket visar att databasens arbetsbelastning förändras med mängden bevarad historik snarare än enbart med processorhastigheten. En varm sidcache kan dölja en del av läskostnaden tills arbetsmängden överskrider minnet eller ett annat arbete tränger undan den.

Definiera kapacitetsfrågan innan du testar: uppstart av instrumentpanelen, historikfråga, automatiseringsfördröjning, händelser per sekund, samtidiga klienter, överlappande säkerhetskopiering eller samtidig körning av tjänster på hela värden. Lista sedan de cacheminnen som kan minska kostnaden för just den operationen. Rensa inte alla cacheminnen urskillningslöst; skapa ett kontrollerat kallt tillstånd och ett realistiskt varmt tillstånd så att båda kan mätas.

Använd kalla och varma körningar för att avgränsa de två användbara ytterligheterna

En kall körning visar hur systemet beter sig när data eller resurser inte finns i minnet, medan en varm körning visar den väg med återanvändning som användare ofta upplever. Ingen av dem är universellt ”verklig”. En telefon som öppnas en gång varje morgon kan ligga närmare ett kallt frontendbeteende, medan en väggmonterad surfplatta eller en hårt belastad databas kan vara varm större delen av dagen.

Anteckningar om lagringsprestanda visar att två körningar efter varandra kan skilja sig enbart eftersom den första värmer upp filsystemets cache. Därför måste kalla och varma cacheförhållanden identifieras i stället för att blandas ihop. Samma princip gäller för tester av Home Assistants historik och resurser: en snabb andra körning är ett tecken på återanvändning, inte i sig ett bevis på större serverkapacitet.

Dokumentera båda fördelningarna, inte bara det bästa resultatet. Använd identiska data, klienter, nätverk och instrumentpanelskonfigurationer. Om varma resultat är utmärkta men kalla resultat överskrider hushållets tidsgräns kan systemet fortfarande vara lämpligt för klienter som alltid är öppna, men dåligt för omstarter, återställning eller sällan använd mobil åtkomst. Kapacitetsanspråk bör ange vilket tillstånd de gäller.

Kapacitet syns när upprepat arbete slutar skala linjärt

För att mäta kapacitet ökar du en arbetsbelastningsvariabel medan de andra hålls konstanta: händelsefrekvens, antal instrumentpanelsklienter, samtidighet för historikfrågor, databasens skrivfrekvens eller belastning från närliggande tjänster. En verklig undersökning av en Home Assistant-instrumentpanel visar hur kontinuerlig WebSocket-uppdateringsbelastning kan bli synlig när klienten hamnar efter, vilket gör köbildning och svansbeteende mer informativa än ett enda toppresultat från cache. Följ dessa signaler tillsammans med processor-, minnes-, lagrings- och nätverksanvändning.

ZimaSpace visar en jämförbar mättnadsmekanism i kökonkurrens i delad lagring: genomströmningen kan förbli hög medan den interaktiva svansfördröjningen ökar efter att mängden pågående arbete överskridit den användbara parallelliteten. Home Assistant kräver på samma sätt latensmedvetna stoppvillkor för kapacitetstester.

Den viktigaste regeln mot marknadsföring är att mer ledig processor inte garanterar större kapacitet för hela systemet. En automatisering kan vänta på en radio, lagringen kan vara mättad medan processorn är inaktiv och en mobil klient kan återge sidan långsamt efter att servern svarat. Kapaciteten gäller hela den testade kedjan och dess konstanta förutsättningar, inte en enda användningsprocent.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Testa cacheutträngning och närliggande tjänster innan du fastslår marginalen

En hemserver kör inte Home Assistant i ett vakuum. Säkerhetskopieringar, mediesökningar, AI-jobb, kamerainspelning, databaser och containrar kan tränga undan användbara cachesidor eller skapa konkurrerande tryck på lagring och minne. Ett riktmärke som körs på en annars tom värd kan därför rapportera en varm arbetsmängd som produktionen inte kan hålla kvar under hushållets verkliga toppbelastning.

Ett optimeringsfall från 2026 för Recorder ger ett praktiskt exempel på att minska mängden historik som skrivs så att databasen kräver mindre I/O och en mindre bevarad arbetsmängd. Det förändrar den verkliga kapacitetsgränsen i stället för att bara få en andra fråga att se snabb ut.

Upprepa stabilitetstestet medan den normala säkerhetskopieringen, kamerabelastningen eller containerarbetsbelastningen körs. Om fördröjningen håller sig inom målet och cacheträffarna förblir stabila är det varma resultatet mer trovärdigt. Om prestandan rasar först efter att en annan tjänst trängt undan cache eller fyllt köer har värden mindre produktionsmarginal än det isolerade Home Assistant-riktmärket antydde.

Publicera ett kapacitetsresultat med sina förutsättningar

Ett användbart resultat anger Home Assistant-version, maskinvara, lagring, databas, antal entiteter, lagringstid, klienttyp, instrumentpanel, nätverksväg, varmt eller kallt tillstånd, bakgrundsarbetsbelastningar, indatafrekvens, testets varaktighet och godkännandetröskel. Utan dessa detaljer kan ”Home Assistant svarar på 100 ms” inte jämföras eller återskapas.

En oberoende analys av samtidighet i Home Assistant förklarar hur asyncio-händelseslingan schemalägger automatiseringsuppgifter och hur I/O-väntan kan pausa dessa uppgifter. Ta med händelseslingans responsivitet och blockerande beteende när den testade arbetsbelastningen främst består av automatiseringar, i stället för att anta att enbart lagrings- eller processoranvändning beskriver kapaciteten.

Kalla systemet kapabelt först när den värsta normala överlappningen körs tillräckligt länge för att nå stabilt tillstånd, svansfördröjningen förblir inom målet, köerna inte fortsätter att växa och upprepade försök ger liknande resultat. Betrakta varm cache som ett drifttillstånd, inte som en multiplikator du kan anta alltid finns kvar när huset och värden samlar på sig fler tjänster.

Vanliga frågor

Bör jag starta om Home Assistant före varje riktmärke?

Nej. En omstart kan skapa ett scenario för kallstart, men den ändrar också många variabler samtidigt. Använd den medvetet för att testa uppstart och kör sedan separata varma och stabila tester utan omstart.

Är den snabbaste körningen den bästa uppskattningen av kapaciteten?

Nej. Den snabbaste körningen visar vanligtvis gynnsamma cache- och schemaläggningsförhållanden. Kapacitetsbeslut bör baseras på upprepningsbara fördelningar och svansfördröjning under varaktig belastning, eftersom användare märker de långsamma körningarna när systemet närmar sig mättnad.

Kan hög cacheträfffrekvens betraktas som något dåligt?

Nej. Återanvändning är önskvärd. Misstaget är att anta att cachade data alltid förblir kvar när arbetsmängd, antal entiteter, historik och närliggande tjänster växer. Mät vad som händer när arbetsbelastningen inte längre ryms bekvämt inom samma cacheavtryck.