Comment mesurer les performances de Home Assistant sans confondre le cache avec la capacité

Un test rapide et à chaud de Home Assistant ne prouve pas l’existence de capacité disponible ; il peut simplement montrer que les caches du navigateur, de la base de données, du système de fichiers ou de l’application sont déjà alimentés.

La capacité correspond à la quantité de travail soutenu qu’un système peut accomplir dans les limites fixées pour la latence et la justesse, tandis que le cache modifie le coût des opérations répétées. Un tableau de bord qui s’ouvre rapidement lors de la deuxième visite, une requête d’historique accélérée par des pages en cache ou un redémarrage suivi d’une automatisation fluide peuvent tous constituer des observations utiles sans révéler la limite de charge. Mesurez séparément les phases à froid, à chaud, en régime stable et en saturation.

Commencez par séparer les effets du cache de la charge à dimensionner

Les différents chemins de Home Assistant disposent de caches différents. Les navigateurs conservent les ressources du frontend ; le système d’exploitation met en cache les pages du système de fichiers ; SQLite ou une autre base de données profite des pages récemment lues ; les intégrations peuvent conserver des connexions ou l’état des appareils ; le DNS et TLS peuvent également être réutilisés. Un seul benchmark « à chaud » peut combiner plusieurs de ces effets.

Un guide de la communauté Home Assistant consacré aux performances de Recorder explique comment une base de données volumineuse génère davantage d’opérations de lecture, d’écriture et d’indexation, montrant que la charge de la base de données varie avec la durée de conservation des états, et pas uniquement avec la vitesse du processeur. Le cache de pages à chaud peut masquer une partie de ce coût de lecture jusqu’à ce que l’ensemble de travail dépasse la mémoire disponible ou qu’une autre charge l’évince.

Définissez la question de capacité avant le test : démarrage du tableau de bord, requête d’historique, latence des automatisations, événements par seconde, clients simultanés, chevauchement avec les sauvegardes ou concurrence des services sur l’ensemble de l’hôte. Énumérez ensuite les caches susceptibles de réduire le coût de cette opération précise. Ne videz pas tous les caches sans distinction ; créez une condition à froid contrôlée et une condition à chaud réaliste afin de pouvoir mesurer les deux.

Utilisez des exécutions à froid et à chaud pour encadrer les deux extrêmes utiles

Une exécution à froid montre le comportement du système lorsque les données ou les ressources ne sont pas résidentes, tandis qu’une exécution à chaud montre le chemin de réutilisation stable que les utilisateurs expérimentent souvent. Aucune des deux conditions n’est universellement « réaliste ». Un téléphone ouvert une fois chaque matin peut être plus proche d’un comportement frontend à froid, tandis qu’une tablette murale ou une base de données très sollicitée peut fonctionner à chaud la majeure partie de la journée.

Les notes consacrées aux benchmarks de stockage indiquent que deux exécutions consécutives peuvent différer simplement parce que la première alimente le cache du système de fichiers ; c’est pourquoi les conditions de cache à froid et à chaud doivent être identifiées plutôt que mélangées. Le même principe s’applique aux tests d’historique et de ressources de Home Assistant : une deuxième exécution rapide prouve la réutilisation, mais ne démontre pas à elle seule une capacité accrue du serveur.

Consignez les deux distributions, et pas seulement la meilleure valeur. Utilisez les mêmes données, le même client, le même réseau et la même configuration du tableau de bord. Si les résultats à chaud sont excellents mais que les résultats à froid dépassent le délai acceptable pour le foyer, le système peut rester adapté aux clients toujours ouverts, tout en étant médiocre lors d’un redémarrage, d’une récupération ou d’un accès mobile occasionnel. Les affirmations de capacité doivent préciser la condition représentée.

La capacité apparaît lorsque le travail répété cesse de progresser linéairement

Pour mesurer la capacité, augmentez une seule variable de charge en maintenant les autres constantes : débit d’événements, nombre de clients du tableau de bord, concurrence des requêtes d’historique, débit d’écriture de la base de données ou charge des services voisins. Une étude réelle d’un tableau de bord Home Assistant montre comment une charge continue de mises à jour WebSocket peut devenir visible lorsque le client prend du retard ; la mise en file d’attente et le comportement en queue sont alors plus instructifs qu’un unique résultat de pointe obtenu avec un cache. Surveillez ces signaux parallèlement à l’utilisation du processeur, de la mémoire, du stockage et du réseau.

ZimaSpace montre un mécanisme de saturation comparable avec la contention des files d’attente du stockage partagé : le débit peut rester élevé tandis que la latence interactive en queue augmente lorsque le travail en attente dépasse le niveau de parallélisme utile. La capacité de Home Assistant nécessite elle aussi des conditions d’arrêt tenant compte de la latence.

La règle essentielle contre les affirmations marketing est la suivante : davantage de processeur libre ne garantit pas une capacité accrue de l’ensemble du système. Une automatisation peut attendre une radio, le stockage peut être saturé alors que le processeur est inactif, et un client mobile peut effectuer un rendu lent après la réponse du serveur. La capacité concerne l’ensemble du chemin testé et les conditions maintenues, et non un seul pourcentage d’utilisation.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Testez l’éviction du cache et les services voisins avant de déclarer une marge disponible

Un serveur domestique n’exécute pas Home Assistant en vase clos. Les sauvegardes, analyses multimédias, tâches d’IA, enregistrements vidéo, bases de données et conteneurs peuvent évincer des pages de cache utiles ou créer une pression concurrente sur le stockage et la mémoire. Un benchmark réalisé sur un hôte par ailleurs inactif peut donc mesurer un ensemble de travail à chaud que la production ne peut pas conserver en mémoire pendant le véritable pic d’activité du foyer.

Un cas pratique d’optimisation de Recorder en 2026 fournit un exemple de réduction du volume d’écritures historiques, afin que la base de données nécessite moins d’E/S et un ensemble de travail conservé plus réduit. Cela modifie la véritable limite de capacité au lieu de rendre simplement une deuxième requête plus rapide.

Répétez le test en régime stable pendant que les charges normales de sauvegarde, de caméra ou de conteneurs s’exécutent. Si la latence reste dans la cible et que le comportement des accès au cache demeure stable, le résultat à chaud est plus crédible. Si les performances ne s’effondrent qu’après qu’un autre service a évincé le cache ou rempli les files d’attente, la marge disponible en production est inférieure à ce que suggérait le benchmark isolé de Home Assistant.

Publiez un résultat de capacité avec ses conditions

Un résultat utile indique la version de Home Assistant, le matériel, le stockage, la base de données, le nombre d’entités, la durée de conservation, le type de client, le tableau de bord, le chemin réseau, la condition à chaud ou à froid, les charges en arrière-plan, le débit d’entrée, la durée du test et le seuil d’acceptation. Sans ces informations, « Home Assistant répond en 100 ms » ne peut être ni comparé ni reproduit.

Une analyse indépendante de la concurrence dans Home Assistant explique comment la boucle d’événements asyncio planifie les tâches d’automatisation et comment les attentes d’E/S peuvent suspendre ces tâches. Lorsque la charge testée est principalement composée d’automatisations, incluez la réactivité de la boucle d’événements et le comportement bloquant, au lieu de supposer que l’utilisation du stockage ou du processeur décrit à elle seule la capacité.

Ne considérez le système comme capable que lorsque le chevauchement normal maximal s’exécute assez longtemps pour atteindre un régime stable, que la latence en queue reste dans la cible, que les files d’attente ne continuent pas à croître et que les essais répétés produisent des résultats similaires. Considérez le cache à chaud comme une condition de fonctionnement parmi d’autres, et non comme un multiplicateur dont vous pouvez supposer la disponibilité permanente à mesure que le foyer et l’hôte accumulent de nouveaux services.

FAQ

Dois-je redémarrer Home Assistant avant chaque benchmark ?

Non. Un redémarrage peut créer un scénario de démarrage à froid, mais il modifie également de nombreuses variables à la fois. Utilisez-le délibérément pour tester le démarrage, puis exécutez séparément les tests à chaud et en régime stable sans redémarrer.

L’exécution la plus rapide est-elle la meilleure estimation de la capacité ?

Non. L’exécution la plus rapide reflète généralement des conditions favorables de cache et de planification. Les décisions de capacité doivent s’appuyer sur des distributions reproductibles et la latence en queue sous charge soutenue, car les utilisateurs remarquent les exécutions lentes lorsque le système approche de la saturation.

Des taux élevés d’accès au cache peuvent-ils être considérés comme négatifs ?

Non. La réutilisation est souhaitable. L’erreur consiste à supposer que les données mises en cache resteront toujours résidentes lorsque l’ensemble de travail, le nombre d’entités, l’historique et les services voisins augmenteront. Mesurez ce qui se produit lorsque la charge ne tient plus confortablement dans la même empreinte de cache.