Tugport optimise les performances de l'API en mettant en cache l'état Docker en mémoire

Tugport, un panneau de gestion Docker auto-hébergé open source, a considérablement amélioré ses temps de réponse API en passant des requêtes Docker en temps réel à une mise en cache en mémoire. À partir de la version 0.1.28, publiée le 26 octobre 2026, l'application sert l'état des services, les métriques d'utilisation du disque et les vérifications de mises à jour à partir de valeurs mises en cache qui sont actualisées en arrière-plan plutôt que de bloquer les demandes des utilisateurs.

Ce qui s'est passé

Avant cette mise à jour, le panneau Tugport souffrait d'une latence notable lors du chargement des listes de projets ou des statistiques du serveur. Chaque demande d'état de service obligeait l'API à lister les conteneurs sur chaque serveur connecté, un processus pouvant prendre environ 100 millisecondes par listing sur un système chargé. De même, le calcul de l'utilisation du disque Docker impliquait la taille de chaque volume, une tâche pouvant prendre plusieurs secondes, tandis que la vérification des mises à jour logicielles à chaque visite de page de paramètres risquait d'atteindre les limites de débit de GitHub pour les appels non authentifiés.

La solution, implémentée dans le commit b460853 via la pull request #39, concerne dix fichiers et 107 lignes de code ajoutées. Le développeur a réalisé que le composant proxy du panneau maintenait déjà une table de routage à jour pour la gestion du trafic. En exposant cet état interne à l'API, le panneau peut répondre aux questions concernant le statut des conteneurs sans interroger directement le démon Docker. Pour les données plus lentes et moins critiques comme l'utilisation du disque et la disponibilité des mises à jour, le système utilise désormais une stratégie « stale-while-revalidate », servant immédiatement les données en cache tout en les actualisant en arrière-plan.

Les tests effectués le 14 novembre 2026 contre le panneau en direct exécutant la version 0.1.35 ont confirmé l'efficacité de ces changements. Le temps nécessaire pour lister tous les services est devenu statistiquement indiscernable de celui du point d'accès API le plus rapide, qui renvoie simplement la version de l'application. La différence de temps de réponse était inférieure au bruit réseau, indiquant que le travail lourd de l'introspection Docker avait été retiré avec succès du chemin critique des demandes des utilisateurs.

Détails clés

• Sortie de version : Les améliorations de la mise en cache ont été introduites dans Tugport v0.1.28 le 26 octobre 2026.
• Mise en cache de l'état des services : L'API lit désormais depuis un instantané partagé des états des conteneurs maintenu par le proxy, qui reconstruit sa table sur les événements Docker et toutes les 30 secondes.
• Gestion des événements : Pour assurer une visibilité immédiate des nouveaux services ou de ceux supprimés, le proxy écoute désormais les événements Docker create et destroy en plus des changements de démarrage, d'arrêt et de santé.
• Fraîcheur de l'utilisation du disque : Les données d'utilisation du disque Docker sont mises en cache pendant cinq minutes, avec des actualisations en arrière-plan garantissant que la première demande après un redémarrage est également rapide.
• Intervalle de vérification des mises à jour : Les vérifications des nouvelles versions sur GitHub sont mises en cache pendant dix minutes pour éviter les limites de débit et réduire les allers-retours externes.
• Résultat de performance : Sur la v0.1.35, le temps de réponse médian du point d'accès /api/services était de 90 ms, comparable aux 87 ms médians pour le point d'accès léger /api/me.

Contexte

Comprendre cette optimisation nécessite d'examiner comment les outils de gestion Docker interagissent généralement avec le démon Docker. La plupart des panneaux interrogent l'API Docker directement chaque fois qu'un utilisateur charge un tableau de bord. Cela implique une communication inter-processus et, dans les configurations distribuées, des appels réseau vers des hôtes distants. Les opérations telles que la liste de tous les conteneurs ou le calcul de la taille des volumes sont coûteuses en ressources car Docker doit inspecter les métadonnées de chaque objet.

Le concept utilisé ici est souvent appelé « stale-while-revalidate ». Au lieu de faire attendre un utilisateur pour des données fraîches, le système sert immédiatement la dernière valeur connue valide. Simultanément, il déclenche un processus en arrière-plan pour récupérer les dernières données. Si la récupération en arrière-plan échoue, le système conserve la valeur ancienne et attend l'intervalle suivant avant de réessayer. Ce modèle est courant dans les navigateurs web pour la mise en cache des actifs, mais il est moins fréquemment appliqué à la gestion de l'état backend dans les outils d'infrastructure, où la précision est souvent prioritaire sur la vitesse.

Pourquoi c'est important

Pour les équipes gérant leur propre infrastructure, la réactivité du tableau de bord est un facteur clé de l'efficacité opérationnelle. Un panneau lent décourage les vérifications fréquentes, ce qui peut entraîner une détection retardée des problèmes. En réduisant la latence des listes de services pour égaler celle des appels de métadonnées simples, Tugport garantit que l'interface reste réactive même lorsque le nombre de conteneurs gérés augmente. C'est particulièrement important pour les auto-hébergeurs qui peuvent exécuter des dizaines de services sur du matériel limité, où chaque milliseconde de temps CPU économisée sur la surveillance peut être allouée aux charges de travail réelles.

De plus, cette approche réduit la charge sur le démon Docker lui-même. La liste constante des conteneurs et le calcul de l'utilisation du disque peuvent consommer des ressources I/O et CPU significatives, surtout sur les serveurs avec beaucoup de volumes ou de builds actifs. En mettant ces résultats en cache, Tugport minimise son empreinte sur le système hôte, laissant plus de ressources disponibles pour les applications qu'il est censé gérer. Cela s'aligne avec l'objectif plus large de l'auto-hébergement : maximiser l'utilité tout en minimisant la friction administrative.

Ce que vous pouvez faire

• Mettre à niveau Tugport : Si vous utilisez Tugport, assurez-vous d'exécuter la version 0.1.28 ou ultérieure pour bénéficier des améliorations de performance.
• Examiner les stratégies de mise en cache : Analysez vos propres outils internes pour des modèles similaires où la précision en temps réel n'est pas strictement nécessaire, et envisagez d'implémenter une logique « stale-while-revalidate » pour les requêtes lourdes.
• Surveiller les événements du proxy : Si vous maintenez des outils similaires, vérifiez que vos écouteurs d'événements couvrent tous les stades du cycle de vie, y compris la création et la destruction, pour éviter des états d'interface obsolètes.
• Vérifier les limites de débit : Auditez tous les appels API externes dans vos outils auto-hébergés, tels que les vérifications de mises à jour GitHub, et implémentez une mise en cache pour éviter d'atteindre les limites de débit lors des pics d'utilisation.
• Benchmarking de votre API : Utilisez des outils pour mesurer la latence des points d'accès sous charge, en comparant les points d'accès de données lourds avec ceux légers pour identifier les potentiels goulets d'étranglement.
• Envisager des workers en arrière-plan : Déchargez les calculs coûteux vers des tâches en arrière-plan qui mettent à jour un magasin d'état partagé, permettant à vos threads API principaux de rester réactifs.