Que met réellement en cache Home Assistant, et quelles requêtes répétées deviennent plus rapides ?
« Home Assistant est plus rapide la deuxième fois » peut décrire plusieurs mécanismes différents. Un navigateur peut réutiliser les ressources de l’interface, un tableau de bord déjà ouvert peut recevoir l’état en temps réel via WebSocket au lieu de reconstruire la page, le système d’exploitation peut conserver en mémoire les pages de la base de données ou de la configuration, et une intégration peut réutiliser une connexion établie.
Regrouper tous ces effets sous le terme « cache de Home Assistant » masque l’endroit où le gain de vitesse se produit. Le modèle utile consiste à nommer la requête répétée, puis à déterminer quelle couche peut éviter du travail lors de la deuxième exécution.
Le cache du navigateur accélère les ressources de l’interface
Le JavaScript, les feuilles de style, les icônes, les cartes personnalisées et autres ressources de l’interface peuvent rester dans le cache du navigateur. Ainsi, lors d’un chargement répété, le navigateur évite de télécharger ou de reconstruire ces mêmes ressources depuis zéro.
Les recommandations actuelles de Home Assistant concernant les navigateurs indiquent explicitement que l’interface utilisateur met de nombreux éléments en cache dans le navigateur afin d’être plus rapide. Ce même cache peut devenir obsolète après une mise à jour ou une modification d’une carte personnalisée, raison pour laquelle un rechargement forcé peut corriger une interface qui fonctionne incorrectement.
Ce cache modifie le démarrage et le rendu de la page, pas la vitesse de contrôle physique des appareils. Le vider constitue un test de l’interface, et non une réinitialisation générale des performances du serveur.
Un tableau de bord ouvert réutilise une connexion WebSocket d’état en temps réel
Une fois l’interface connectée, elle n’a pas besoin de récupérer à nouveau l’intégralité de l’état de la maison connectée à chaque changement. Elle reçoit les mises à jour et les abonnements via l’API WebSocket, puis actualise les composants concernés de l’interface.
L’architecture actuelle de l’interface décrit comment l’interface reçoit l’état central via un objet hass partagé et maintient la synchronisation des données supplémentaires auxquelles elle est abonnée grâce aux WebSockets. Une tablette murale qui reste connectée suit donc un chemin de requête répétée différent de celui d’un téléphone qui ouvre le tableau de bord à froid chaque matin.
Ne considérez pas cette réutilisation comme la preuve que l’ajout de nombreux clients permettra une montée en charge linéaire. Chaque client supplémentaire peut encore ajouter du travail de sérialisation, de gestion des abonnements, de récupération de l’historique et de rendu côté client.
Le cache de pages Linux accélère les lectures répétées de fichiers et de bases de données
Les lectures normales du système de fichiers passent par le cache de pages Linux. Les pages de base de données récemment utilisées, les fichiers de configuration et les ressources statiques peuvent rester en mémoire et éviter une nouvelle lecture physique du stockage lors d’une requête répétée.
La documentation actuelle du noyau Linux explique que les lectures normales de fichiers alimentent le cache de pages, afin que les lectures suivantes puissent éviter un accès plus coûteux au stockage. Ainsi, une requête répétée dans l’historique peut bénéficier de la mémoire, même si Home Assistant n’a pas implémenté de cache spécial au niveau de l’application pour cette requête précise.
C’est pourquoi les différences entre SSD et HDD peuvent sembler moins importantes lors d’un test à chaud qu’après un redémarrage, une éviction du cache ou avec un ensemble de travail beaucoup plus volumineux.
Des données déjà en mémoire ne signifient pas que la requête sous-jacente est devenue moins coûteuse
Une requête d’historique peut toujours parcourir ou indexer la même quantité logique de données, tandis que les pages nécessaires se trouvent simplement déjà en mémoire. Un tableau de bord peut toujours demander les mêmes entités, alors que les ressources et l’état de la connexion sont déjà disponibles.
Le guide de référence ZimaSpace associé sur la séparation entre les performances avec cache à chaud et la capacité réelle en montre la conséquence opérationnelle : le cache est utile, mais une affirmation concernant la capacité doit résister à une pression réaliste sur le cache et à une charge de travail soutenue.
Un accès réussi au cache supprime un coût pour une requête donnée. Il ne supprime pas le travail du processeur, de la mémoire, du réseau, de la base de données ou des intégrations qui intervient aux autres étapes du parcours.
Des requêtes répétées différentes réchauffent des couches différentes
- Recharger le même tableau de bord : les ressources du navigateur et l’environnement d’exécution côté client peuvent être déjà en mémoire.
- Laisser une tablette murale ouverte : l’état WebSocket et les abonnements restent actifs.
- Répéter la même plage d’historique : les pages de la base de données et du système de fichiers peuvent rester en mémoire.
- Appeler le même service local : les connexions d’intégration ou réseau déjà établies peuvent encore exister.
- Ouvrir après un redémarrage : plusieurs de ces couches peuvent être froides simultanément.
Mesurez la couche qui correspond à l’action de l’utilisateur au lieu de vider tous les caches et de qualifier cela de « scientifique ».
FAQ
Vider le cache du navigateur rend-il Home Assistant Core plus lent ?
Cela modifie principalement le chemin de chargement de l’interface. Core exécute toujours la même logique serveur, mais le navigateur peut devoir télécharger et reconstruire les ressources, ce qui ralentit le premier chargement de l’interface.
Une requête d’historique à chaud est-elle inutile pour les tests de performance ?
Non. Les requêtes à chaud représentent une condition de fonctionnement réelle. L’erreur consiste à considérer le résultat à chaud comme le seul indicateur de capacité, alors que la pression mémoire, un redémarrage ou un ensemble de travail plus volumineux peuvent supprimer ce même avantage du cache.
Produits recommandés
Centre Tech & IA
Plus à lire
État d’exécution vs état persistant dans Home Assistant : que doit survivre à un redémarrage ?
Home Assistant ne conserve pas chaque valeur en temps réel ; la configuration, les registres, certains états restaurés, l’historique et les données de déploiement...
Comment Home Assistant authentifie-t-il les sessions locales et distantes ?
Les sessions Home Assistant locales et distantes utilisent le même modèle d’identité côté serveur ; l’accès à distance modifie le chemin et la limite...
Pourquoi les requêtes d’historique de Home Assistant peuvent-elles ralentir à mesure que les données de l’enregistreur augmentent ?
L’augmentation du nombre d’enregistrements peut accroître le coût des requêtes d’historique lorsque la plage demandée concerne davantage de lignes, que les défauts de cache...
