Quantos utilizadores consegue o Home Assistant suportar num pequeno servidor doméstico?

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

O Home Assistant não tem um limite universal de utilizadores; um servidor pequeno suporta apenas as sessões simultâneas cujas cargas de trabalho reais se mantenham dentro dos objetivos definidos de latência e recuperação.

As contas nomeadas são económicas quando a maioria das pessoas está inativa, enquanto alguns painéis muito utilizados podem solicitar histórico, transmitir câmaras, processar cartões personalizados e consumir atualizações frequentes por WebSocket. O acesso remoto pode acrescentar limitações do proxy e do carregamento que os testes locais não revelam. Por isso, a capacidade deve ser expressa como carga de trabalho simultânea com um nível de serviço aceitável, e não como o número de pessoas guardadas no registo de utilizadores.

As Contas Registadas Não São Carga de Trabalho Simultânea

Uma conta acrescenta sobretudo identidade e permissões até alguém estabelecer ligação. Um telemóvel com sessão iniciada e uma ligação em segundo plano consome mais recursos do que uma conta inativa, e um painel de parede com muitas câmaras pode consumir mais do que vários utilizadores a abrir vistas simples de controlo.

Uma pergunta da comunidade sobre utilizadores simultâneos mostra que a carga de trabalho de utilizadores simultâneos não tem uma conversão documentada simples em CPU ou memória, porque o comportamento dos clientes varia muito.

Conte as sessões WebSocket ativas, as vistas do painel, as consultas ao histórico, as transmissões e as chamadas de serviço durante o mesmo intervalo. O total de utilizadores registados continua a ser útil para a administração, mas não para prever o desempenho.

O Design do Painel Altera o Custo por Utilizador

Um painel simples subscreve um conjunto limitado de entidades, enquanto gráficos, mapas, câmaras, cartões personalizados e modelos abrangentes acrescentam consultas ao servidor, transferência de rede e processamento no cliente. As atualizações frequentes de entidades multiplicam-se em todas as sessões subscritas.

As discussões sobre design para várias unidades e utilizadores expõem os problemas de isolamento e organização relacionados com o design de instâncias multiutilizador, e não apenas um número bruto de ligações.

Separe a segmentação do agregado familiar do desempenho. Uma instância pode servir tecnicamente vários grupos, mas ainda assim proporcionar limites inadequados de privacidade ou administração; aumentar a capacidade do hardware não resolve essa restrição de design.

O Cliente e a Rede Podem Falhar Antes do Servidor

Os processadores dos dispositivos móveis, a memória do navegador, a qualidade do Wi-Fi, a latência da VPN, a configuração do proxy e a largura de banda de carregamento da ligação doméstica podem dominar a velocidade percecionada. Um servidor pode responder prontamente enquanto um dispositivo demora segundos a processar uma vista complexa.

Um caso em que os painéis eram lentos no telemóvel, mas rápidos num computador, demonstra por que motivo o atraso do painel no lado do cliente deve ser medido separadamente da resposta do servidor.

Compare clientes locais e remotos com a mesma vista. Se os registos de data e hora do servidor permanecerem estáveis, mas o tempo de processamento divergir, aumentar a capacidade do servidor não elevará o número prático de utilizadores nesse percurso do cliente.

-15% OFF

A Difusão de Eventos Cria o Limite de Saturação

Cada novo estado pode ser enviado para muitos clientes ligados, e cada vista pode desencadear trabalho adicional de modelos ou histórico. A CPU, a memória, a latência da base de dados e a largura de banda de saída podem, por isso, aumentar de forma não linear quando as sessões ocupadas se sobrepõem.

Uma investigação sobre spam de eventos WebSocket relaciona um painel lento com o volume de atualizações, ilustrando como a difusão de atualizações por WebSocket pode dominar mesmo quando o número de pessoas é reduzido.

Este é o limite de falha: o número de utilizadores não é a causa, a menos que a adição repetida de sessões idênticas aumente de forma correlacionada um recurso e a latência do serviço. Tempestades de integrações, cartões problemáticos e falhas de rede devem ser corrigidos antes de declarar que o servidor está cheio.

Encontre a Capacidade com um Teste de 2-4-8 Sessões

Crie um perfil de teste representativo e execute duas sessões simultâneas, depois quatro e, por fim, oito. Em cada etapa, repita o carregamento de um painel, uma consulta fixa ao histórico, uma chamada de serviço inofensiva e uma vista de câmara, registando a latência p95, a CPU, a memória, a fila de armazenamento e a largura de banda de saída.

A estrutura de teste de utilizadores simultâneos fornece uma estrutura de diagnóstico para utilizadores simultâneos, ajudando a definir as métricas e a condição de paragem para um servidor pequeno com Home Assistant.

Pare no primeiro nível que não cumpra o objetivo de latência do agregado familiar ou que apresente saturação sustentada; o nível anterior que passou é a capacidade testada para essa carga de trabalho, e não uma garantia universal. Repita o teste remotamente e durante a atividade normal das automatizações, reservando depois margem para cópias de segurança, atualizações e tempestades de reconexões.

Centro de Tecnologia e IA

Mais para Ler

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.