Tugport optimiza el rendimiento de la API al cachear el estado de Docker en memoria

Tugport, un panel de gestión de Docker autoalojado y de código abierto, ha mejorado significativamente sus tiempos de respuesta de la API al pasar de consultas en tiempo real a Docker a un caché en memoria. A partir de la versión 0.1.28, lanzada el 26 de octubre de 2026, la aplicación sirve el estado de los servicios, las métricas de uso de disco y las comprobaciones de actualizaciones desde valores cacheados que se refrescan en segundo plano, en lugar de bloquear las solicitudes de los usuarios.

Qué ocurrió

Antes de esta actualización, el panel Tugport sufría de una latencia notable al cargar listas de proyectos o estadísticas del servidor. Cada solicitud del estado de un servicio requería que la API listara los contenedores en cada servidor conectado, un proceso que podía tomar aproximadamente 100 milisegundos por listado en un sistema ocupado. De manera similar, calcular el uso de disco de Docker implicaba dimensionar cada volumen, una tarea que podía tardar segundos, mientras que comprobar las actualizaciones de software en cada visita a la página de configuración arriesgaba alcanzar los límites de tasa de GitHub para llamadas no autenticadas.

La solución, implementada en el commit b460853 mediante la pull request #39, involucra diez archivos y 107 líneas de código añadidas. El desarrollador se dio cuenta de que el componente proxy del panel ya mantenía una tabla de enrutamiento actualizada para la gestión del tráfico. Al exponer este estado interno a la API, el panel puede responder preguntas sobre el estado de los contenedores sin consultar directamente al daemon de Docker. Para datos más lentos y menos críticos, como el uso de disco y la disponibilidad de actualizaciones, el sistema ahora utiliza una estrategia stale-while-revalidate, sirviendo datos cacheados inmediatamente mientras los refresca en segundo plano.

Las pruebas realizadas el 14 de noviembre de 2026, contra el panel en vivo ejecutando la versión 0.1.35, confirmaron la eficacia de estos cambios. El tiempo necesario para listar todos los servicios se volvió estadísticamente indistinguible del endpoint de API más rápido, que simplemente devuelve la versión de la aplicación. La diferencia en los tiempos de respuesta fue menor que el ruido de red, lo que indica que la carga pesada de la introspección de Docker había sido exitosamente removida de la ruta crítica de las solicitudes de usuario.

Detalles clave

• Lanzamiento de versión: Las mejoras de caché fueron introducidas en Tugport v0.1.28 el 26 de octubre de 2026.
• Caché de estado de servicio: La API ahora lee desde una instantánea compartida de estados de contenedor mantenida por el proxy, que reconstruye su tabla ante eventos de Docker y cada 30 segundos.
• Manejo de eventos: Para asegurar la visibilidad inmediata de nuevos o eliminados servicios, el proxy ahora escucha eventos create y destroy de Docker además de los cambios de inicio, parada y salud.
• Frescura del uso de disco: Los datos de uso de disco de Docker se cachean durante cinco minutos, con refrescos en segundo plano que aseguran que la primera solicitud tras un reinicio también sea rápida.
• Intervalo de comprobación de actualizaciones: Las comprobaciones de nuevas versiones en GitHub se cachean durante diez minutos para evitar límites de tasa y reducir viajes externos.
• Resultado de rendimiento: En v0.1.35, el tiempo de respuesta mediano del endpoint /api/services fue de 90 ms, comparable a los 87 ms medianos del endpoint ligero /api/me.

Contexto

Entender esta optimización requiere observar cómo las herramientas de gestión de Docker interactúan típicamente con el daemon de Docker. La mayoría de los paneles consultan la API de Docker directamente cada vez que un usuario carga un dashboard. Esto implica comunicación entre procesos y, en configuraciones distribuidas, llamadas de red a hosts remotos. Operaciones como listar todos los contenedores o calcular el tamaño de los volúmenes son computacionalmente costosas porque Docker debe inspeccionar los metadatos de cada objeto.

El concepto utilizado aquí se conoce a menudo como "stale-while-revalidate". En lugar de hacer esperar al usuario por datos frescos, el sistema sirve el último valor conocido bueno inmediatamente. Simultáneamente, dispara un proceso en segundo plano para obtener los últimos datos. Si la obtención en segundo plano falla, el sistema retiene el valor antiguo y espera al siguiente intervalo antes de intentarlo de nuevo. Este patrón es común en navegadores web para cachear activos, pero se aplica con menos frecuencia a la gestión de estado backend en herramientas de infraestructura, donde la precisión suele priorizarse sobre la velocidad.

Por qué importa

Para equipos que gestionan su propia infraestructura, la capacidad de respuesta del dashboard es un factor clave en la eficiencia operativa. Un panel lento desalienta las comprobaciones frecuentes, lo que potencialmente lleva a una detección retrasada de problemas. Al reducir la latencia de los listados de servicios para igualar la de las llamadas simples de metadatos, Tugport asegura que la interfaz se sienta ágil incluso a medida que crece el número de contenedores gestionados. Esto es particularmente importante para quienes hacen self-hosting y pueden ejecutar decenas de servicios en hardware limitado, donde cada milisegundo de CPU ahorrado en sobrecarga de monitoreo puede asignarse a cargas de trabajo reales.

Además, este enfoque reduce la carga sobre el propio daemon de Docker. Listar constantemente contenedores y calcular el uso de disco puede consumir recursos significativos de I/O y CPU, especialmente en servidores con muchos volúmenes o builds activos. Al cachear estos resultados, Tugport minimiza su huella en el sistema host, dejando más recursos disponibles para las aplicaciones que está destinado a gestionar. Esto se alinea con el objetivo más amplio del self-hosting: maximizar la utilidad mientras se minimiza la fricción administrativa.

Qué puedes hacer

• Actualiza Tugport: Si estás usando Tugport, asegúrate de estar ejecutando la versión 0.1.28 o posterior para beneficiarte de las mejoras de rendimiento.
• Revisa estrategias de caché: Examina tus propias herramientas internas para patrones similares donde la precisión en tiempo real no sea estrictamente necesaria, y considera implementar lógica stale-while-revalidate para consultas pesadas.
• Monitorea eventos del proxy: Si mantienes herramientas similares, verifica que tus oyentes de eventos cubran todas las etapas del ciclo de vida, incluyendo creación y destrucción, para evitar estados de UI obsoletos.
• Comprueba límites de tasa: Audita cualquier llamada a API externa en tus herramientas autoalojadas, como las comprobaciones de actualización de GitHub, e implementa caché para prevenir alcanzar los límites de tasa durante picos de uso.
• Haz benchmark de tu API: Usa herramientas para medir la latencia de endpoints bajo carga, comparando endpoints de datos pesados contra ligeros para identificar posibles cuellos de botella.
• Considera workers en segundo plano: Descarga cálculos costosos a tareas en segundo plano que actualicen un almacén de estado compartido, permitiendo que tus hilos principales de API permanezcan receptivos.