hariri.ch
Prenez contact

Humour Tech ~1 min de lecture

Le cache peut cacher un N+1 jusqu’au prochain cold start

« La page est rapide. » « Oui, tant que le cache fait le travail de la base. »

Diagramme en deux colonnes comparant un workflow trompeur et un workflow utile. Colonne de gauche, verdict ok: “Warm cache”, puis “Hit cache”, “Réponse rapide”, “SQL non observé”. Colonne de droite, verdict fail: “Cold cache”, puis “Miss cache”, “N+1 / requête lourde”, “DB lente”, “Pic de latence”. Le contraste montre que le cache peut masquer un problème de base de données.
Le diagramme montre qu’un endpoint peut sembler sain en warm cache alors que le flux réel en cold cache révèle un N+1 ou une requête trop coûteuse.

Le cache applicatif peut donner une impression trompeuse de performance. Tant que la réponse est servie depuis le cache, une route semble rapide. Mais après une invalidation, un cold start ou un changement de clé, le coût réel réapparaît d’un coup.

Le problème est souvent en dessous: N+1, jointure coûteuse, index manquant, ou requête acceptable sur petit volume mais lente à grande échelle. Le cache améliore l’expérience utilisateur, mais il ne corrige pas la cause.

Le bon réflexe est simple: pour chaque endpoint critique, mesurer deux chemins dans un environnement de test comparable.

  • warm cache: temps total observé
  • cold cache: temps total et nombre de requêtes SQL

Si l’écart est énorme, le cache masque probablement un problème de base de données ou d’accès aux données qu’il faut traiter avant le prochain restart.

Publié par :

Dans le même esprit

À lire ensuite