Fonctionnement

Cette page explique la mécanique. Vous n'en avez pas strictement besoin pour utiliser Cache Rocket, mais comprendre la boucle d'exécution rend chaque paramètre du formulaire warmer évident au lieu de mystérieux.

La vie d'une course au chaud#

Un warmer est une configuration enregistrée, pas un processus en cours d'exécution. Il reste inactif jusqu'à ce que quelque chose démarre une exécution. Lorsqu'une course commence, voici la séquence :

1. 1

   Démarrer la file d'attente

   Cache Rocket prend vos URL d'entrée et, si activé, développe tous les plans de site qu'il trouve. Ceux-ci deviennent les premiers éléments de la file d’attente d’analyse.

2. 2

   Vérifier l'autorisation

   Chaque URL est vérifiée par rapport à votre vérifié hostnames. Tout ce qui pointe vers un domaine dont vous n'avez pas prouvé que vous êtes propriétaire est supprimé avant l'envoi d'une seule demande.

3. 3

   Demander une URL

   Cache Rocket récupère l'URL via HTTP avec vos en-têtes, cookies et agent utilisateur configurés, et enregistre la durée de la réponse. C'est le premier chargement.

4. 4

   Demandez-le à nouveau

   Immédiatement après, il récupère la même URL une deuxième fois. C'est la charge chaude. Étant donné que la première requête a rempli le cache, la seconde devrait être considérablement plus rapide.

5. 5

   Découvrez plus d'URL

   Les liens trouvés dans le HTML sont ajoutés à la file d'attente, tant qu'ils restent sur un hostname vérifié, ne sont pas exclus et sont dans votre limite de profondeur.

6. 6

   Répéter dans les limites

   La file d'attente est traitée à un rythme maximum de votre nombre maximal d'URL par minute et s'arrête lorsque la file d'attente se vide ou qu'une limite du plan est atteinte.

7. 7

   Enregistrer et notifier

   Flux de résultats Santé du cache. Si l'exécution a échoué ou comporte de nombreuses erreurs, vos [Alertes] (/documentation/alerts) configurées se déclenchent.

La double récupération, et pourquoi c'est important#

Récupérer chaque URL deux fois est la chose la plus intelligente que fasse Cache Rocket, et cela sert deux objectifs à la fois.

Le premier objectif est le réchauffement. La première requête paie la pénalité de démarrage à froid : elle oblige votre origine à créer la page et chaque cache devant elle pour stocker le résultat. Cache Rocket se porte volontaire pour être le visiteur qui attend, afin qu'une vraie personne ne soit pas obligée de le faire.

Le deuxième objectif est la preuve. En chronométrant les deux requêtes, Cache Rocket peut vous montrer la différence. Un premier chargement de 1 800 ms suivi d'un chargement à chaud de 90 ms est la preuve sans ambiguïté que le cache s'est rempli. Si les deux chiffres sont lents, votre mise en cache ne fonctionne pas et le réchauffement seul ne vous sauvera pas – ce qui est en soi extrêmement utile à savoir.

Comment les URL sont découvertes#

Un warmer trouve du travail de trois manières, et ils se cumulent :

URL d'entrée

Les points de départ que vous saisissez à la main. Toujours utilisé. Pour de nombreux sites, une seule URL d’entrée – la page d’accueil – suffit.

Plans du site

Si Inclure les plans de site est activé et qu'une URL d'entrée pointe vers un plan de site .xml, chaque URL répertoriée à l'intérieur est ajoutée. C'est le moyen fiable de couvrir des sites volumineux, car votre CMS gère la liste pour vous.

Lien suivant

Cache Rocket lit le code HTML qu'il récupère et met en file d'attente les liens qu'il trouve, sans aller plus loin que ce que permet votre paramètre profondeur. Cela capture les pages qui ne figurent dans aucun plan de site.

La profondeur est mesurée en sauts à partir d'une URL d'entrée. Votre page d'accueil a une profondeur de 0. Tout ce qui est lié directement à partir de celle-ci est de profondeur 1. Tout ce qui est lié à partir de *ces* pages est de profondeur 2, et ainsi de suite.

depth 0   https://example.com/                     ← entry URL
depth 1   https://example.com/blog/
          https://example.com/pricing
          https://example.com/about
depth 2   https://example.com/blog/warming-101
          https://example.com/blog/cdn-basics
depth 3   https://example.com/blog/author/sam

Qu'est-ce qui déclenche une course#

Si une [fenêtre de programmation chaude] (/documentation/advanced-warming) est configurée, les démarrages automatiques planifiés tombant en dehors des heures autorisées sont ignorés. Les démarrages manuels et les déclencheurs de déploiement fonctionnent toujours.

Les garde-corps#

Un cache warmer est, structurellement, un robot poli qui envoie de nombreuses requêtes sur un site Web. Cache Rocket prend cela au sérieux et le restreint de trois manières.

Cela ne concerne que les domaines que vous possédez

Chaque hostname doit être vérifié via DNS ou un fichier HTTPS avant de pouvoir apparaître dans un warmer. Il ne s’agit pas d’une friction facultative : sans cela, le service pourrait être pointé vers le serveur de quelqu’un d’autre comme un outil de déni de service. Voir Hostname vérification.

Il respecte une limite de vitesse que vous fixez

Le nombre maximal d'URL par minute constitue un plafond strict en matière de taux de requêtes. Réglez-le sur ce que votre hébergement peut confortablement absorber *en plus* du trafic réel. L'hébergement partagé peut en vouloir 5 à 10 ; une origine bien provisionnée derrière un CDN peut souvent en gérer plusieurs centaines.

Il reste dans les limites de votre forfait

Votre abonnement limite le nombre d'URL par minute, jour, semaine et mois, ainsi que la profondeur d'exploration et le nombre de warmers. Lorsqu'une limite est atteinte, l'exécution s'arrête proprement plutôt que de dépasser. Voir Plans et limites.

Où vivent les pièces#