Combien d’utilisateurs Home Assistant un petit serveur domestique peut-il prendre en charge ?

Home Assistant n’impose aucune limite universelle d’utilisateurs ; un petit serveur ne prend en charge que les sessions simultanées dont les charges de travail réelles restent dans les objectifs définis de latence et de récupération.

Les comptes nominatifs coûtent peu lorsque la plupart des utilisateurs sont inactifs, tandis que quelques tableaux de bord sollicités peuvent demander l’historique, diffuser des caméras, afficher des cartes personnalisées et consommer des mises à jour WebSocket fréquentes. L’accès à distance peut ajouter des contraintes liées au proxy et au débit montant que les tests locaux ne révèlent pas. La capacité doit donc être exprimée en charge de travail simultanée à un niveau de service acceptable, et non en nombre de personnes enregistrées dans le registre des utilisateurs.

Les comptes enregistrés ne correspondent pas à la charge de travail simultanée

Un compte ajoute principalement une identité et des autorisations jusqu’à ce qu’une personne se connecte. Un téléphone connecté avec une connexion en arrière-plan coûte davantage qu’un compte dormant, et un panneau mural riche en caméras peut coûter plus cher que plusieurs utilisateurs ouvrant de simples vues de contrôle.

Une question de la communauté sur les utilisateurs simultanés montre que la charge de travail des utilisateurs simultanés ne peut pas être convertie simplement et de manière documentée en besoins en processeur ou en mémoire, car le comportement des clients varie considérablement.

Comptez les sessions WebSocket actives, les vues de tableau de bord, les requêtes d’historique, les flux vidéo et les appels de service pendant le même intervalle. Le nombre total d’utilisateurs enregistrés reste utile pour l’administration, mais pas pour prévoir les performances.

La conception du tableau de bord modifie le coût par utilisateur

Un tableau de bord simple s’abonne à un ensemble limité d’entités, tandis que les graphiques, les cartes, les caméras, les cartes personnalisées et les modèles étendus ajoutent des requêtes serveur, du transfert réseau et du rendu côté client. Les mises à jour fréquentes des entités se multiplient pour chaque session abonnée.

Les discussions sur la conception multi-unités et multi-utilisateurs mettent en évidence les problèmes d’isolation et d’organisation liés à la conception d’une instance multi-utilisateurs, et pas uniquement un nombre brut de connexions.

Faites la distinction entre la segmentation du foyer et les performances. Une instance peut techniquement servir plusieurs groupes tout en offrant des limites de confidentialité ou d’administration inadaptées ; augmenter la puissance matérielle ne résout pas cette contrainte de conception.

Le client et le réseau peuvent tomber en panne avant le serveur

Les processeurs mobiles, la mémoire du navigateur, la qualité du Wi-Fi, la latence du VPN, la configuration du proxy et le débit montant de la connexion domestique peuvent dominer la vitesse perçue. Un serveur peut répondre rapidement tandis qu’un appareil met plusieurs secondes à afficher une vue complexe.

Un cas où les tableaux de bord étaient lents sur mobile mais rapides sur ordinateur montre pourquoi le retard d’affichage côté client doit être mesuré séparément de la réponse du serveur.

Comparez les clients locaux et distants avec la même vue. Si les horodatages du serveur restent stables mais que le temps de rendu diverge, augmenter la capacité du serveur n’accroîtra pas le nombre pratique d’utilisateurs pour ce chemin client.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

La distribution des événements crée le seuil de saturation

Chaque nouvel état peut être transmis à de nombreux clients connectés, et chaque vue peut déclencher un travail supplémentaire lié aux modèles ou à l’historique. Le processeur, la mémoire, la latence de la base de données et la bande passante sortante peuvent donc augmenter de manière non linéaire lorsque des sessions très sollicitées se chevauchent.

Une enquête sur le spam d’événements WebSocket relie un tableau de bord lent au volume de mises à jour, illustrant comment la distribution des mises à jour WebSocket peut devenir le facteur dominant même lorsque le nombre de personnes est faible.

C’est la limite de défaillance : le nombre d’utilisateurs n’est pas la cause, sauf si l’ajout répété de sessions identiques augmente de manière corrélée une ressource et la latence du service. Les tempêtes d’intégrations, les cartes défectueuses et les problèmes réseau doivent être corrigés avant de déclarer le serveur saturé.

Déterminez la capacité avec un test à 2, 4 et 8 sessions

Créez un profil de test représentatif et exécutez deux sessions simultanées, puis quatre et enfin huit. À chaque étape, répétez le chargement d’un tableau de bord, une requête d’historique fixe, un appel de service sans effet indésirable et l’affichage d’une caméra, tout en enregistrant la latence p95, l’utilisation du processeur, la mémoire, la file d’attente du stockage et la bande passante sortante.

Le cadre de test des utilisateurs simultanés fournit une méthode de diagnostic des utilisateurs simultanés et aide à définir les métriques ainsi que le seuil d’arrêt pour un petit serveur Home Assistant.

Arrêtez-vous au premier niveau qui ne respecte plus l’objectif de latence du foyer ou qui montre une saturation persistante ; le niveau précédent ayant réussi constitue la capacité testée pour cette charge de travail, et non une garantie universelle. Répétez le test à distance et pendant l’activité habituelle des automatisations, puis prévoyez une marge pour les sauvegardes, les mises à jour et les vagues de reconnexions.