Hur många samtidiga användare klarar Home Assistant innan det börjar gå långsammare?

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.

Home Assistant har inget användbart universellt svar som ”20 användare” eller ”100 användare”. Ett inloggat konto som är inaktivt skapar en annan belastning än en väggmonterad surfplatta som renderar en komplex instrumentpanel, en telefon som öppnar Historik eller flera användare som tittar på kamerakort medan tusentals entiteter uppdateras.

Dimensionera för samtidig användning genom att mäta anslutna klienter och det arbete varje klient orsakar. Den praktiska gränsen går där dina representativa instrumentpaneler, WebSocket-uppdateringar, serveråtgärder och nätverksväg börjar överskrida den svarstid du anser vara acceptabel.

Räkna anslutna klienter, inte bara användarkonton

Att skapa 100 konton innebär inte 100 samtidiga sessioner. Omvänt kan en person ha en webbläsare, telefon, surfplatta och kiosk anslutna samtidigt.

Home Assistants WebSocket-integration kan visa sensor.connected_clients som det aktuella antalet anslutna WebSocket-klienter. Använd detta antal som en signal för samtidighet medan du återskapar belastningen.

Registrera antalet klienter tillsammans med serverns CPU-användning, minnesbelastning, nätverkstrafik och åtgärdernas svarstid. Ett anslutningsantal utan den bakomliggande belastningen är inget kapacitetsresultat.

Frontendkostnaden beror på tillståndsuppdateringar och instrumentpanelsarbete

Frontend skapar en WebSocket-anslutning och håller Home Assistants tillstånd synkroniserat med webbläsaren. Varje klient måste också rendera den instrumentpanel som öppnas, så klienthårdvara och anpassade kort kan bli begränsningar innan servern blir det.

Den aktuella frontendarkitekturen beskriver hur frontend tar emot kärntillstånd och ytterligare prenumerationer via WebSocket-API:t. En aktiv installation skapar därför kontinuerligt uppdateringsarbete efter den första sidinläsningen.

Testa den faktiska blandningen av instrumentpaneler som hushållet använder i stället för att öppna en tom testsida på varje klient.

Hög uppdateringsfrekvens för entiteter kan belasta klienterna innan användarantalet verkar stort

Ett system med tusentals sensorer som ändras ofta kan skicka betydligt mer frontendarbete än en större användargrupp som huvudsakligen visar statiska entiteter. Detta märks särskilt på äldre surfplattor och resurssnåla väggpaneler.

Ett Home Assistant-ärende dokumenterade ett fall där stora mängder entitetsuppdateringar överbelastade instrumentpanelsklienterna även när den synliga instrumentpanelen var enkel.

Det definierar inte någon universell tröskel, men visar varför ”användare” är fel som enda måttenhet. Mät uppdateringar per sekund och klienternas responsivitet tillsammans med anslutningsantalet.

Det finns inget publicerat maximum för hushållsskala att kopiera

Frågor från communityn om ovanligt stora installationer illustrerar osäkerheten. I en diskussion om ungefär 200 användare framkom inget tydligt maximalt antal som stöds, och den skalan betraktades som ett ovanligt användningsfall som bör testas i stället för att tas för given.

För ett vanligt hushåll innebär detta att du inte behöver jaga ett leverantörsaktigt maxantal sessioner. För en gemensam entré, en delad byggnad, ett labb eller annan installation med många användare kanske Home Assistant inte är rätt plattform för identitets- och åtkomsthantering, även om servern tekniskt kan upprätthålla anslutningarna.

ZimaSpaces metod för dimensionering utifrån samtidig belastning gäller även här: kapaciteten bör kopplas till den mest intensiva realistiska överlappningen, inte till det totala antalet registrerade konton.

Genomför ett stegtest tills ett mått upprepade gånger visar felet

Steg Mät Stoppa när
Lägg till aktiva klienter i små grupper Anslutna klienter Representativ samtidighet har uppnåtts
Öppna riktiga instrumentpaneler Första rendering och interaktionsfördröjning Upprepad fördröjning som användaren märker
Generera normal entitetstrafik WebSocket-/uppdateringsbelastning Klienterna hinner inte med
Utför vanliga åtgärder Fördröjning från serveråtgärd till enhet Styrfördröjningen ökar märkbart
Upprepa vid toppbelastning CPU, minne, nätverk och klientbelastning Samma begränsande lager visar sig igen

Välj en kapacitet ett steg under den första upprepningsbara felpunkten och lämna utrymme för säkerhetskopieringar, uppdateringar, kameratrafik och ovanliga belastningstoppar. Om bara en gammal surfplatta blir långsam medan serveråtgärderna fortfarande är snabba, kanske ett serverbyte inte ökar den användbara samtidigheten.

Vanliga frågor

Motsvarar 20 Home Assistant-användarkonton 20 samtidiga användare?

Nej. Konton är identiteter; samtidighet handlar om aktiva klientanslutningar och det arbete dessa klienter skapar. En användare kan ha flera klienter, medan många konton kan vara helt inaktiva.

Gör enklare instrumentpaneler att alltid fler användare kan ansluta?

De kan minska klienternas renderingsarbete, men serverkapaciteten beror också på entiteternas uppdateringsfrekvens, WebSocket-trafik, historikfrågor, kameror, nätverksväg och bakgrundstjänster. Mät hela belastningen.

Support och tips

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.