Ilu użytkowników może obsługiwać Home Assistant na małym serwerze domowym?

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Home Assistant nie ma uniwersalnego limitu użytkowników; mały serwer obsługuje tylko tyle jednoczesnych sesji, ile mieści się w określonych celach dotyczących opóźnień i odzyskiwania sprawności.

Imienne konta są tanie pod względem zasobów, gdy większość osób jest nieaktywna, natomiast kilka intensywnie używanych pulpitów może żądać historii, przesyłać obraz z kamer, renderować niestandardowe karty i zużywać zasoby przez częste aktualizacje WebSocket. Zdalny dostęp może dodatkowo wprowadzać ograniczenia serwera proxy i wysyłania danych, których nie widać w testach lokalnych. Dlatego przepustowość należy wyrażać jako liczbę jednoczesnych obciążeń przy akceptowalnym poziomie usług, a nie jako liczbę osób zapisanych w rejestrze użytkowników.

Zarejestrowane konta to nie to samo co jednoczesne obciążenie

Konto dodaje głównie tożsamość i uprawnienia, dopóki ktoś się nie połączy. Zalogowany telefon z połączeniem działającym w tle zużywa więcej zasobów niż nieaktywne konto, a panel ścienny intensywnie korzystający z kamer może obciążać serwer bardziej niż kilku użytkowników otwierających proste widoki sterowania.

Jedno z pytań społeczności dotyczących jednoczesnych użytkowników pokazuje, że obciążenia generowanego przez jednoczesnych użytkowników nie da się łatwo przeliczyć na procesor ani pamięć, ponieważ zachowanie klientów znacznie się różni.

W tym samym przedziale czasu zliczaj aktywne sesje WebSocket, widoki pulpitów, zapytania o historię, strumienie i wywołania usług. Łączna liczba zarejestrowanych użytkowników pozostaje przydatna do celów administracyjnych, ale nie do prognozowania wydajności.

Projekt pulpitu zmienia koszt obsługi użytkownika

Prosty pulpit subskrybuje ograniczony zestaw encji, natomiast wykresy, mapy, kamery, niestandardowe karty i rozbudowane szablony zwiększają liczbę zapytań do serwera, transfer danych w sieci oraz obciążenie renderowania po stronie klienta. Częste aktualizacje encji mnożą się dla każdej subskrybującej sesji.

Dyskusje dotyczące projektowania dla wielu jednostek i użytkowników pokazują problemy z izolacją i organizacją związane z projektowaniem instancji dla wielu użytkowników, a nie tylko surową liczbą połączeń.

Oddziel segmentację gospodarstwa domowego od kwestii wydajności. Jedna instancja może technicznie obsługiwać kilka grup, ale zapewniać nieodpowiednie granice prywatności lub administracji; zwiększenie mocy sprzętu nie rozwiązuje tego ograniczenia projektowego.

Klient i sieć mogą zawieść przed serwerem

Procesor urządzenia mobilnego, pamięć przeglądarki, jakość Wi-Fi, opóźnienia VPN, konfiguracja serwera proxy i przepustowość wysyłania danych z domu mogą dominować nad odczuwaną szybkością działania. Serwer może odpowiadać szybko, podczas gdy jedno urządzenie spędza kilka sekund na renderowaniu złożonego widoku.

Przypadek, w którym pulpity działały wolno na urządzeniu mobilnym, ale szybko na komputerze, pokazuje, dlaczego opóźnienie pulpitu po stronie klienta należy mierzyć osobno od czasu odpowiedzi serwera.

Porównuj klientów lokalnych i zdalnych, korzystając z tego samego widoku. Jeśli znaczniki czasu serwera pozostają stabilne, ale czas renderowania się różni, zwiększenie wydajności serwera nie zwiększy praktycznej liczby użytkowników na tej ścieżce klienta.

-15% OFF

Rozsyłanie zdarzeń do wielu klientów wyznacza granicę nasycenia

Każdy nowy stan może być dostarczany do wielu połączonych klientów, a każdy widok może uruchamiać dodatkowe przetwarzanie szablonów lub historii. W efekcie obciążenie procesora i pamięci, opóźnienia bazy danych oraz przepustowość wychodząca mogą rosnąć nieliniowo, gdy intensywne sesje nakładają się na siebie.

Analiza nadmiarowych zdarzeń WebSocket łączy powolny pulpit z dużą liczbą aktualizacji, pokazując, jak rozsyłanie aktualizacji WebSocket może zdominować obciążenie, nawet gdy liczba osób jest niewielka.

To jest granica awarii: liczba użytkowników nie jest przyczyną problemu, chyba że wielokrotne dodawanie identycznych sesji powoduje skorelowany wzrost zużycia zasobów i opóźnienia usług. Zanim uznasz, że serwer osiągnął limit, napraw skokowe obciążenia integracji, wadliwe karty i usterki sieci.

Znajdź przepustowość za pomocą testu dla 2, 4 i 8 sesji

Utwórz jeden reprezentatywny profil testowy i uruchom kolejno dwie, cztery, a następnie osiem jednoczesnych sesji. Na każdym etapie powtórz wczytywanie pulpitu, ustalone zapytanie o historię, nieszkodliwe wywołanie usługi i wyświetlenie obrazu z kamery, rejestrując opóźnienie p95, użycie procesora i pamięci, kolejkę operacji pamięci masowej oraz przepustowość wychodzącą.

Struktura testu jednoczesnych użytkowników zapewnia ramy diagnostyczne dla takiego testu, pomagając określić metryki i warunek zakończenia dla małego serwera Home Assistant.

Zakończ test na pierwszym poziomie, na którym nie zostanie osiągnięty docelowy poziom opóźnień dla gospodarstwa domowego lub pojawi się trwałe nasycenie zasobów; poprzedni poziom, który przeszedł test, jest przepustowością sprawdzoną dla danego obciążenia, a nie uniwersalną gwarancją. Powtórz test zdalnie i podczas normalnego działania automatyzacji, a następnie pozostaw zapas zasobów na kopie zapasowe, aktualizacje i skokowe obciążenia powodowane ponownym nawiązywaniem połączeń.

Centrum Technologii i Sztucznej Inteligencji

Więcej do przeczytania

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.