Comment évaluer la marge de ressources de Home Assistant avec une charge de travail reproductible

Un benchmark de performances de Home Assistant n’est utile que lorsqu’il reproduit la même charge de travail et définit ce que signifie « suffisamment rapide » avant d’examiner les graphiques de ressources. Sinon, les chiffres concernant le processeur, la mémoire, le stockage et le réseau restent de simples observations, sans conclusion sur la capacité.

Cette démarche diffère du dépannage d’une installation lente. Un benchmark crée délibérément une base de référence reproductible, augmente une seule dimension de la charge de travail et détermine la marge de ressources restante avant qu’une automatisation choisie, qu’une requête d’historique ou que la réponse d’un tableau de bord ne dépasse sa plage de latence acceptable.

Définir une charge de travail et un seuil d’acceptation

Choisissez une charge de travail représentant un pic réel du foyer : par exemple, une automatisation locale déclenchée par un mouvement, trois tableaux de bord actifs, des écritures Recorder normales, une période en arrière-plan sans sauvegarde et un ensemble fixe d’intégrations. Notez la version de Home Assistant, le matériel hôte, le stockage, la base de données, le client, le chemin réseau et la durée du test.

La vue Informations système de Home Assistant présente le contexte de l’installation, du réseau, des intégrations et des ressources, qui doit être consigné avec tout résultat de performance. Sans détails sur l’environnement, le temps de réponse d’une personne ne peut pas être comparé de manière pertinente à celui d’une autre machine.

Définissez ensuite le seuil d’acceptation. Une automatisation d’éclairage peut nécessiter une réponse physique inférieure à une seconde, tandis qu’une requête d’historique sur cinq ans peut être acceptable en plusieurs secondes. Ne regroupez pas ces deux cas dans un score générique de « rapidité de Home Assistant ».

Utiliser l’utilisation, la saturation et les erreurs pour chaque ressource partagée

L’utilisation moyenne seule constitue un mauvais critère d’arrêt. Un disque peut être très sollicité tout en restant sain, ou un processeur peut afficher une utilisation moyenne modérée alors que de brèves pointes créent une file d’attente perceptible sous forme de latence.

La méthode USE évalue l’utilisation, la saturation et les erreurs pour chaque ressource physique ou limitée. Appliquez cette approche au processeur, à la capacité mémoire, aux E/S du stockage et aux interfaces réseau, plutôt que de choisir le graphique affichant la plus forte utilisation.

Pour Home Assistant conteneurisé, considérez également les limites cgroup comme des ressources. Un hôte disposant de 60 % de processeur libre peut tout de même ralentir un conteneur ayant atteint le quota qui lui est attribué.

Les métriques de pression montrent le temps perdu à cause de la pénurie de ressources

Le Pressure Stall Information de Linux apporte une vue orientée vers la latence. Au lieu de demander uniquement quelle quantité de processeur, de mémoire ou d’E/S est utilisée, le PSI mesure la fraction du temps pendant laquelle les tâches sont bloquées parce qu’une ressource est disputée.

La documentation du noyau Linux explique que la pression exercée sur le processeur, la mémoire et les E/S peut être mesurée comme le temps réel perdu à cause de la contention, y compris lors de brèves pointes qui dégradent la latence avant que l’utilisation moyenne ne paraisse extrême.

Le PSI est donc utile sur un serveur domestique partagé. Si la latence de Home Assistant se dégrade lorsque la pression sur les E/S augmente pendant la rafale d’écritures d’un autre conteneur, vous disposez de preuves plus solides d’une contention du stockage partagé qu’avec la seule affirmation « le SSD était utilisé à 70 % ».

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

N’augmenter qu’une seule dimension de la charge de travail par exécution

N’ajoutez pas simultanément des utilisateurs de tableaux de bord, des déclencheurs d’automatisation, des flux de caméras, de la rétention et du trafic de sauvegarde. Augmentez une seule variable en maintenant toutes les autres conditions constantes.

Les tests par paliers utiles incluent l’augmentation du nombre d’événements d’automatisation par minute, du nombre de tableaux de bord simultanés, de la taille des plages d’historique, du nombre de mises à jour d’entités ou d’une charge définie d’un service voisin. Après chaque palier, attendez suffisamment longtemps pour que le système atteigne un comportement stable, plutôt que de recueillir les dix premières secondes correspondant à un cache chaud ou à une rafale de démarrage.

L’analyse de ZimaSpace consacrée à la contention des files d’attente de stockage partagé et à la latence de queue montre pourquoi la charge de travail doit être reliée au chemin de la ressource : le stockage n’a d’importance que lorsque l’action testée en dépend directement ou partage la même file d’attente d’E/S.

Modifier une seule ressource et exiger que le résultat évolue

Un benchmark devient diagnostique lorsqu’une modification contrôlée d’une ressource déplace la courbe de latence. Éloignez un service voisin fortement sollicité du processeur de Home Assistant, mettez en pause une tâche générant beaucoup d’écritures, augmentez la limite mémoire cgroup testée, utilisez une liaison LAN directe ou déplacez les données des applications vers un stockage à latence plus faible.

Si le seuil de latence initial s’améliore au même palier de charge, la ressource constituait vraisemblablement une contrainte pour la marge disponible. Si rien ne change, annulez l’expérience et testez le candidat suivant au lieu de transformer cette modification en configuration permanente.

Présenter le résultat sous forme d’enveloppe de capacité

Le résultat final devrait être formulé ainsi : « Ce matériel, cette base de données, ce mélange de clients et cette charge de travail en arrière-plan maintiennent le chemin de contrôle choisi dans l’objectif jusqu’au palier N. » Cette affirmation est reproductible. « Home Assistant n’utilise que 20 % du processeur » ne l’est pas.