¿Cuántos usuarios puede admitir Home Assistant en un pequeño servidor doméstico?

Eva Wong

IceWhale author

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

How Many Users Can Home Assistant Support on a Small Home Server?

Home Assistant no tiene un límite de usuarios universal; un servidor pequeño solo admite las sesiones simultáneas cuyas cargas de trabajo reales se mantengan dentro de los objetivos definidos de latencia y recuperación.

Las cuentas nominales son económicas cuando la mayoría de las personas están inactivas, mientras que unos pocos paneles activos pueden solicitar historiales, transmitir cámaras, mostrar tarjetas personalizadas y consumir actualizaciones frecuentes de WebSocket. El acceso remoto puede añadir limitaciones del proxy y de la velocidad de carga que las pruebas locales no detectan. Por lo tanto, la capacidad debe expresarse como carga de trabajo simultánea con un nivel de servicio aceptable, no como el número de personas almacenadas en el registro de usuarios.

Las cuentas registradas no equivalen a carga de trabajo simultánea

Una cuenta principalmente añade identidad y permisos hasta que alguien se conecta. Un teléfono conectado con una conexión en segundo plano consume más recursos que una cuenta inactiva, y un panel mural con muchas cámaras puede consumir más que varios usuarios que abren vistas de control sencillas.

Una pregunta de la comunidad sobre los usuarios simultáneos muestra que la carga de trabajo de los usuarios simultáneos no tiene una conversión documentada sencilla a CPU o memoria, porque el comportamiento de los clientes varía considerablemente.

Cuenta las sesiones activas de WebSocket, las vistas de los paneles, las consultas de historial, las transmisiones y las llamadas de servicio durante el mismo intervalo. El total de usuarios registrados sigue siendo útil para la administración, no para predecir el rendimiento.

El diseño del panel cambia el coste por usuario

Un panel sencillo se suscribe a un conjunto limitado de entidades, mientras que los gráficos, mapas, cámaras, tarjetas personalizadas y plantillas amplias añaden consultas al servidor, transferencia de red y renderizado en el cliente. Las actualizaciones frecuentes de entidades se multiplican en cada sesión suscrita.

Los debates sobre el diseño para varias unidades y varios usuarios ponen de manifiesto los problemas de aislamiento y organización relacionados con el diseño de instancias multiusuario, no simplemente con un total bruto de conexiones.

Separa la segmentación del hogar del rendimiento. Una instancia puede atender técnicamente a varios grupos y, aun así, ofrecer límites de privacidad o administración inadecuados; ampliar el hardware no resuelve esa restricción de diseño.

El cliente y la red pueden fallar antes que el servidor

Los procesadores móviles, la memoria del navegador, la calidad de la Wi-Fi, la latencia de la VPN, la configuración del proxy y el ancho de banda de subida de la conexión doméstica pueden dominar la velocidad percibida. Un servidor puede responder rápidamente mientras un dispositivo tarda varios segundos en renderizar una vista compleja.

Un caso en el que los paneles eran lentos en un móvil, pero rápidos en un ordenador, demuestra por qué el retraso del panel en el cliente debe medirse por separado de la respuesta del servidor.

Compara clientes locales y remotos con la misma vista. Si las marcas de tiempo del servidor permanecen estables, pero el tiempo de renderizado difiere, aumentar la capacidad del servidor no incrementará el número práctico de usuarios para esa ruta del cliente.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

La distribución de eventos crea el límite de saturación

Cada nuevo estado puede enviarse a muchos clientes conectados, y cada vista puede activar trabajo adicional de plantillas o historiales. Por lo tanto, la CPU, la memoria, la latencia de la base de datos y el ancho de banda saliente pueden aumentar de forma no lineal cuando se solapan sesiones ocupadas.

Una investigación sobre el exceso de eventos de WebSocket relaciona un panel lento con el volumen de actualizaciones, e ilustra cómo la distribución de actualizaciones de WebSocket puede dominar incluso cuando el número de personas es reducido.

Este es el límite de fallo: el número de usuarios no es la causa, a menos que añadir sesiones idénticas eleve repetidamente un recurso correlacionado y la latencia del servicio. Las oleadas de integraciones, las tarjetas defectuosas y los fallos de red deben corregirse antes de declarar que el servidor está saturado.

Encuentra la capacidad con una prueba de 2, 4 y 8 sesiones

Crea un perfil de prueba representativo y ejecuta dos sesiones simultáneas, después cuatro y luego ocho. En cada etapa, repite la carga de un panel, una consulta de historial fija, una llamada de servicio inocua y una vista de cámara, mientras registras la latencia p95, la CPU, la memoria, la cola de almacenamiento y el ancho de banda saliente.

El marco de pruebas de usuarios simultáneos proporciona un marco de diagnóstico para usuarios simultáneos que ayuda a definir las métricas y la condición de detención para un servidor pequeño de Home Assistant.

Detente en el primer nivel que no cumpla el objetivo de latencia del hogar o que muestre una saturación sostenida; el nivel anterior que sí lo superó es la capacidad probada para esa carga de trabajo, no una promesa universal. Repite la prueba de forma remota y durante la actividad normal de las automatizaciones, y reserva margen para copias de seguridad, actualizaciones y oleadas de reconexiones.