Cache HTTP Gateway

Le cache que le Hub place devant les applications : son efficacité, son remplissage, et la purge.

Voir l'élément dans l'écran : cache/dashboard

Explication

Quand un visiteur demande une page à une application, la requête passe par le reverse proxy du Hub. Pour les routes dont le cache est activé, le Hub garde une copie de la réponse et la resert lui-même aux visiteurs suivants, sans déranger l'application.

Le cache a deux étages :

• L1, en mémoire du Hub : très rapide, limité en nombre d'entrées, perdu au redémarrage ;
• L2, dans Redis : plus grand, conservé au redémarrage du Hub, chaque entrée avec sa durée de vie.

Une réponse trouvée en L2 remonte en L1. Quand L1 est plein, l'entrée la plus ancienne sort.

Cet écran montre l'efficacité du cache (taux de succès), son remplissage, et les applications qui y ont des entrées. Il sert surtout à purger : après la mise en ligne d'une nouvelle version, pour que les visiteurs voient tout de suite le nouveau contenu.

Fiche complète

Ce que l'écran appelle

GET /hub/cache → cache_worker.cache_stats

Réponse de l'action

{ "enabled": true, "hitRate": 87.5, "totalHits": 14000, "totalMisses": 2000,
  "l1Size": 640, "l1MaxSize": 1000,
  "per_app": { "things.exemplia.example": 420, "notionsocle.exemplia.example": 180 } }

Réglage par application

La politique de cache vit sur la route de l'application (apps.proxy_routes.datas, cachePolicy) : activée ou non, TTL des pages (300 s par défaut), TTL des fichiers statiques (86 400 s par défaut), respect de Cache-Control, 5 000 entrées au plus. Elle se règle par l'action cache_worker.cache_configure : l'écran n'a pas de formulaire pour cela, bien que le contrôleur expose POST /hub/cache/{appId}/configure.

Interrupteur général

soclehub.cache.enabled. Cache désactivé : toutes les actions répondent sans rien faire, et les compteurs restent à zéro.