Caching

Un workflow qui exécute npm ci à chaque push télécharge depuis le registre les mêmes centaines de paquets à chaque fois, même quand le lockfile n’a pas changé depuis une semaine. Sur un projet avec un arbre de dépendances réel, ce sont une ou deux minutes perdues avant même que le premier test démarre, et vous les payez de nouveau à chaque push et à chaque pull request. actions/cache conserve ces téléchargements d’une exécution à l’autre et vous les restitue quand rien de pertinent n’a changé. ...

Ce qu’un CDN fait réellement à une requête Un utilisateur à Tokyo qui charge une page hébergée sur un serveur en Virginie paie cette distance deux fois : une fois pour que la requête arrive, une fois pour que la réponse revienne. La fibre optique transporte les données à une fraction fixe de la vitesse de la lumière, et ce seul trajet coûte déjà 150 à 200 ms d’aller-retour avant même que l’origine n’ait commencé à travailler. Ajoutez une requête en base de données et un ou deux sauts réseau lents, et une page qui semble instantanée juste à côté devient poussive à l’autre bout de la planète. ...

Une requête qui prend 200ms sur votre base de données prend toujours 200ms la millionième fois que quelqu’un l’exécute, et chacune de ces exécutions se dispute les mêmes connexions, le même I/O disque et le même CPU. Redis garde la réponse en mémoire, sur un serveur qui ne fait que ça, si bien que la millionième lecture coûte un aller-retour réseau au lieu d’un plan de requête. Ce que Redis fait réellement comme cache Redis est un magasin clé-valeur en mémoire. Les valeurs vivent en RAM, donc les lectures et écritures prennent moins d’une milliseconde, contre les dizaines ou centaines de millisecondes que coûte une requête relationnelle dès que des jointures, des index sous pression ou un pool de connexions chargé entrent en jeu. Il se place à côté de votre base de données, pas à sa place : votre application interroge d’abord Redis et ne va à la base de données que si Redis n’a pas la réponse. ...