Cómo medir el rendimiento de Home Assistant sin confundir la caché con la capacidad

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.

Una prueba rápida en caliente de Home Assistant no demuestra que haya capacidad disponible; puede demostrar únicamente que las cachés del navegador, la base de datos, el sistema de archivos o la aplicación ya están pobladas.

La capacidad es la cantidad de trabajo sostenido que un sistema puede completar dentro de un objetivo de latencia y corrección, mientras que la caché modifica el coste del trabajo repetido. Un panel que se abre rápidamente en la segunda visita, una consulta del historial acelerada por páginas en caché o un reinicio seguido de una automatización fluida pueden ser observaciones útiles sin mostrar el límite de carga de trabajo. Mide por separado las fases en frío, en caliente, de estado estable y de saturación.

Separa primero los efectos de la caché de la carga de trabajo que quieres dimensionar

Las distintas rutas de Home Assistant tienen cachés diferentes. Los navegadores conservan los recursos del frontend; el sistema operativo almacena en caché las páginas del sistema de archivos; SQLite u otra base de datos se benefician de las páginas leídas recientemente; las integraciones pueden mantener conexiones o el estado de los dispositivos; además, DNS y TLS también pueden reutilizarse. Una única prueba comparativa «en caliente» puede incluir varios de estos efectos a la vez.

Una guía de la comunidad de Home Assistant sobre el rendimiento de Recorder explica cómo una base de datos grande genera más trabajo de lectura, escritura e indexación, demostrando que la carga de trabajo de la base de datos cambia según el estado retenido, no solo según la velocidad de la CPU. La caché de páginas en caliente puede ocultar parte de ese coste de lectura hasta que el conjunto de trabajo supera la memoria disponible o otra carga de trabajo lo expulsa.

Define la pregunta de capacidad antes de realizar la prueba: inicio del panel, consulta del historial, latencia de las automatizaciones, eventos por segundo, clientes simultáneos, coincidencia con copias de seguridad o concurrencia de servicios en todo el host. Después, enumera las cachés que pueden reducir esa operación específica. No borres todas las cachés indiscriminadamente; crea una condición fría controlada y otra condición caliente realista para poder medir ambas.

Usa ejecuciones en frío y en caliente para delimitar los dos extremos útiles

Una ejecución en frío muestra cómo se comporta el sistema cuando los datos o recursos no están residentes, mientras que una ejecución en caliente muestra la ruta de reutilización estable que los usuarios suelen experimentar. Ninguna es universalmente «real». Un teléfono que se abre una vez cada mañana puede acercarse más al comportamiento frío del frontend, mientras que una tableta mural o una base de datos ocupada pueden funcionar en caliente durante la mayor parte del día.

Las notas sobre pruebas de almacenamiento indican que dos ejecuciones consecutivas pueden diferir simplemente porque la primera calienta la caché del sistema de archivos, por lo que deben identificarse las condiciones de caché fría y caliente en lugar de mezclarlas. El mismo principio se aplica a las pruebas del historial y los recursos de Home Assistant: una segunda ejecución rápida demuestra reutilización, pero por sí sola no demuestra una mayor capacidad del servidor.

Registra ambas distribuciones, no solo el mejor resultado. Usa los mismos datos, cliente, red y configuración del panel. Si los resultados en caliente son excelentes, pero los resultados en frío superan el plazo aceptable del hogar, el sistema puede ser adecuado para clientes siempre abiertos, pero deficiente después de un reinicio, durante la recuperación o para accesos móviles esporádicos. Las afirmaciones de capacidad deben indicar la condición que representan.

La capacidad aparece cuando el trabajo repetido deja de escalar linealmente

Para medir la capacidad, aumenta una única variable de carga mientras mantienes constantes las demás: tasa de eventos, clientes del panel, concurrencia de consultas del historial, tasa de escritura de la base de datos o carga de servicios vecinos. Una investigación real sobre paneles de Home Assistant muestra cómo la carga continua de actualizaciones por WebSocket puede hacerse visible cuando el cliente empieza a retrasarse, por lo que el comportamiento de las colas y de la latencia de cola resulta más informativo que un único resultado máximo con caché. Observa esas señales junto con el uso de CPU, memoria, almacenamiento y red.

ZimaSpace muestra un mecanismo de saturación comparable en la contención de colas del almacenamiento compartido: el rendimiento puede mantenerse alto mientras aumenta la latencia de cola interactiva después de que el trabajo pendiente supera el paralelismo útil. La capacidad de Home Assistant requiere las mismas condiciones de parada basadas en la latencia.

La regla clave contra el marketing engañoso es que tener más CPU libre no garantiza una mayor capacidad de todo el sistema. Una automatización puede esperar a una radio, el almacenamiento puede estar saturado mientras la CPU permanece inactiva y un cliente móvil puede renderizar lentamente después de que el servidor responda. La capacidad pertenece a toda la ruta probada y a las condiciones mantenidas, no a un único porcentaje de utilización.

-15% OFF

Prueba la expulsión de caché y los servicios vecinos antes de declarar margen disponible

Un servidor doméstico no ejecuta Home Assistant en el vacío. Las copias de seguridad, los análisis multimedia, los trabajos de IA, las grabaciones de cámaras, las bases de datos y los contenedores pueden expulsar páginas útiles de la caché o crear presión adicional sobre el almacenamiento y la memoria. Por tanto, una prueba realizada en un host que, por lo demás, está vacío puede informar de un conjunto de trabajo caliente que la producción no puede mantener residente durante el pico real del hogar.

Un caso práctico de optimización de Recorder de 2026 ofrece un ejemplo de reducción del volumen de escritura histórica para que la base de datos requiera menos E/S y un conjunto de trabajo retenido menor. Esto cambia el límite real de capacidad, en lugar de limitarse a hacer que una segunda consulta parezca rápida.

Repite la prueba de estado estable mientras se ejecutan las cargas normales de copias de seguridad, cámaras o contenedores. Si la latencia se mantiene dentro del objetivo y el comportamiento de los aciertos de caché permanece estable, el resultado en caliente será más creíble. Si el rendimiento se desploma solo después de que otro servicio expulsa la caché o llena las colas, el host tiene menos margen disponible en producción del que sugería la prueba aislada de Home Assistant.

Publica el resultado de capacidad junto con sus condiciones

Un resultado útil indica la versión de Home Assistant, el hardware, el almacenamiento, la base de datos, el número de entidades, la retención, el tipo de cliente, el panel, la ruta de red, la condición fría o caliente, las cargas de trabajo en segundo plano, la tasa de entrada, la duración de la prueba y el umbral de aceptación. Sin esos detalles, «Home Assistant responde en 100 ms» no se puede comparar ni reproducir.

Un análisis independiente de la concurrencia de Home Assistant explica cómo el bucle de eventos asyncio programa las tareas de automatización y cómo las esperas de E/S pueden suspenderlas. Incluye la capacidad de respuesta del bucle de eventos y el comportamiento de las operaciones bloqueantes cuando la carga probada depende mucho de las automatizaciones, en lugar de asumir que el uso del almacenamiento o de la CPU describe por sí solo la capacidad.

Considera que el sistema tiene capacidad únicamente cuando la peor coincidencia normal se ejecuta el tiempo suficiente para alcanzar el estado estable, la latencia de cola permanece dentro del objetivo, las colas no siguen creciendo y las pruebas repetidas producen resultados similares. Trata la caché caliente como una condición operativa más, no como un multiplicador que puedas asumir que seguirá disponible a medida que la casa y el host acumulen más servicios.

Preguntas frecuentes

¿Debería reiniciar Home Assistant antes de cada prueba comparativa?

No. Un reinicio puede crear un escenario de arranque en frío, pero también cambia muchas variables a la vez. Úsalo deliberadamente para probar el inicio y después realiza pruebas independientes en caliente y en estado estable sin reiniciar.

¿Es la ejecución más rápida la mejor estimación de la capacidad?

No. La ejecución más rápida suele mostrar condiciones favorables de caché y planificación. Las decisiones de capacidad deben basarse en distribuciones reproducibles y en la latencia de cola bajo carga sostenida, porque los usuarios perciben las ejecuciones lentas cuando el sistema se acerca a la saturación.

¿Pueden considerarse negativas las tasas altas de aciertos de caché?

No. La reutilización es deseable. El error consiste en suponer que los datos almacenados en caché permanecerán siempre residentes a medida que crecen el conjunto de trabajo, el número de entidades, el historial y los servicios vecinos. Mide qué ocurre cuando la carga de trabajo deja de caber cómodamente en la misma huella de 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.