¿Qué almacena realmente en caché Home Assistant y qué solicitudes repetidas se vuelven más rápidas?

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.

«Home Assistant es más rápido la segunda vez» puede describir varios mecanismos diferentes. Un navegador puede reutilizar recursos del frontend, un panel ya abierto puede recibir el estado en tiempo real mediante WebSocket en lugar de reconstruir la página, el sistema operativo puede mantener en memoria páginas de la base de datos o de configuración, y una integración puede reutilizar una conexión establecida.

Llamar a todos esos efectos «la caché de Home Assistant» oculta dónde se produce la aceleración. El modelo útil consiste en nombrar la solicitud repetida y, después, identificar qué capa puede evitar trabajo en la segunda ejecución.

La caché del navegador acelera los recursos del frontend

JavaScript, estilos, iconos, tarjetas personalizadas y otros recursos del frontend pueden permanecer en la caché del navegador, de modo que una carga repetida de la página evita descargar o reconstruir los mismos recursos desde cero.

La guía actual de Home Assistant para navegadores señala explícitamente que la interfaz de usuario almacena muchas cosas en la caché del navegador para funcionar rápidamente. Esa misma caché puede quedar obsoleta después de actualizaciones o cambios en tarjetas personalizadas, por lo que una actualización completa puede solucionar una interfaz que funciona incorrectamente.

Esta caché modifica el inicio y la representación de la página, no la velocidad del control físico de los dispositivos. Borrarla es una prueba del frontend, no un restablecimiento general del rendimiento del servidor.

Un panel abierto reutiliza una ruta de estado WebSocket en tiempo real

Una vez conectado el frontend, no necesita volver a solicitar todo el estado del hogar inteligente cada vez que se produce un cambio. Recibe actualizaciones y suscripciones a través de la API de WebSocket y actualiza los componentes relevantes de la interfaz.

La arquitectura actual del frontend describe cómo el frontend recibe el estado principal mediante un objeto hass compartido y mantiene sincronizados datos adicionales suscritos mediante WebSockets. Por tanto, una tableta mural que permanece conectada sigue una ruta de solicitudes repetidas diferente a la de un teléfono que abre el panel en frío cada mañana.

No interpretes esta reutilización como una prueba de que muchos más clientes escalarán de forma lineal. Cada cliente adicional aún puede añadir trabajo de serialización, suscripciones, solicitudes de historial y representación en el lado del cliente.

La caché de páginas de Linux acelera las lecturas repetidas de archivos y bases de datos

Las lecturas normales del sistema de archivos pasan por la caché de páginas de Linux. Las páginas de bases de datos utilizadas recientemente, los archivos de configuración y los recursos estáticos pueden permanecer en la memoria y evitar otra lectura física del almacenamiento en una solicitud repetida.

La documentación actual del kernel de Linux explica que las lecturas normales de archivos llenan la caché de páginas, de modo que las lecturas posteriores pueden evitar un acceso de almacenamiento más costoso. Esto significa que una consulta repetida del historial puede beneficiarse de la memoria incluso cuando Home Assistant no haya implementado una caché especial a nivel de aplicación para esa consulta concreta.

Por eso, las diferencias entre SSD y HDD pueden parecer menores en una prueba con la caché caliente que después de reiniciar, expulsar la caché o utilizar un conjunto de trabajo mucho mayor.

Los datos calientes no significan que la consulta subyacente se haya vuelto más barata

Una solicitud del historial puede seguir examinando o indexando la misma cantidad lógica de datos, mientras las páginas que necesita casualmente permanecen en la memoria. Un panel puede seguir solicitando las mismas entidades mientras los recursos y el estado de la conexión ya están disponibles.

La guía de referencia relacionada de ZimaSpace sobre separar el rendimiento con la caché caliente de la capacidad real muestra la consecuencia operativa: la caché es útil, pero una afirmación sobre capacidad debe mantenerse bajo una presión de caché realista y una carga de trabajo sostenida.

Un acierto de caché elimina un coste de una solicitud. No elimina el trabajo de CPU, memoria, red, base de datos o integración que corresponde a otras etapas de la ruta.

Las distintas solicitudes repetidas calientan capas diferentes

  • Volver a cargar el mismo panel: los recursos del navegador y el entorno de ejecución del cliente pueden estar calientes.
  • Mantener abierta una tableta mural: el estado de WebSocket y las suscripciones permanecen activos.
  • Repetir el mismo intervalo del historial: las páginas de la base de datos y del sistema de archivos pueden permanecer en la memoria.
  • Llamar al mismo servicio local: es posible que ya existan conexiones de integración o de red establecidas.
  • Abrir después de reiniciar: varias de esas capas pueden estar frías al mismo tiempo.

Mide la capa que corresponde a la acción del usuario en lugar de borrar todas las cachés y llamar a eso «científico».

Preguntas frecuentes

¿Borrar la caché del navegador hace que Home Assistant Core sea más lento?

Principalmente cambia la ruta de carga del frontend. Core sigue ejecutando la misma lógica del servidor, pero el navegador puede tener que descargar y reconstruir los recursos de nuevo, lo que hace que la primera carga de la interfaz sea más lenta.

¿Una consulta del historial con la caché caliente no sirve para hacer pruebas de rendimiento?

No. Las consultas calientes representan una condición de funcionamiento real. El error consiste en tratar el resultado en caliente como el único resultado de capacidad, cuando la presión de memoria, un reinicio o un conjunto de trabajo mayor pueden eliminar esa misma ventaja de la caché.

Centro de Tecnología e IA

Más para leer

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.