préchauffer le cacher

Explorons en détail la problématique du préchauffage du cache. Partons à la découverte des différences entre Cache hit et Cache miss, les avantages et désavantages du préchauffage du cache, et ce que nous avons mis en place via notre moteur.

L’arsenal de notre solution SaaS est varié pour déployer une stratégie de cache cohérente et performante : le Smart Cache qui permet la mise en cache de page dynamique, le cookieless cache pour les utilisateurs sans sessions actives, ou encore le cache gérant plusieurs variations de page pour le mobile, la langue ou le magasin.

Cependant, le cache de Fasterize n’est performant que s’il est chaud et correctement alimenté. L’alimentation du cache se fait de façon passive au fur et à mesure des requêtes entrantes effectuées par les internautes. Le préchargement du cache via un crawler est d’autant plus intéressant lorsque :

    • le trafic du site est faible en comparaison de la taille du catalogue produit
    • ou que la probabilité pour que plusieurs utilisateur.rice.s demandent la même variation d’une page est faible.

Cache hit vs. Cache miss

Le cache de Fasterize stocke une ou plusieurs variations des fichiers constituant une page Web afin de les distribuer plus rapidement. En mettant en cache des copies des images, CSS et HTML, le serveur d'origine n'a pas besoin de générer ces fichiers chaque fois qu'un.e nouveau.elle visiteur.se accède au site Web. Cela améliore le temps de chargement de la page et réduit la pression sur le serveur d'origine. Ainsi, un site Web peut servir plus d’internautes à la fois !

Les sites de e-commerce mettant constamment à jour l'inventaire de leurs produits, les fichiers expirent après une période définie qui peut aller d’une minute à plusieurs heures. Or, chaque fois qu'un fichier dans le cache expire, celui-ci doit être récupéré à nouveau depuis le serveur d'origine.

La première visite, après l’installation initiale d’un cache ou l’expiration d’un cache, passe par un cache vide ou froid et rencontre un "cache miss" Le cache transmet la requête au serveur d’origine pour récupérer le fichier et le transmettre au navigateur. Bien sûr, il conserve par la même occasion le fichier dans le cache qui est donc complet, ou chaud. Chaque utilisateur.rice suivant qui visite ce même site avant l'expiration du cache sera alors servi depuis le cache. On parle alors d’un "cache hit".

En résumé, un cache hit correspond à une requête ayant été servie par le cache alors qu’un cache miss correspond à une requête servie par l’origine. Autrement dit, un cache froid ne contient pas encore les fichiers, et un cache chaud contient déjà des fichiers et est prêt à servir les internautes.

Préchauffage du cache : avantages et inconvénients

Il y a tout intérêt à ce que les internautes rencontrent un cache hit pour être servie.s. rapidement. Cependant, à moins que les sites ne se mettent à préchauffer le cache, certains internautes rencontrent un cache miss après l'expiration du contenu ou le vidage du cache. L’expérience est alors dégradée.

Le préchauffage du cache consiste alors à remplir artificiellement le cache, de sorte que les visiteur.se.s réelle.s accèdent au cache. Essentiellement, cela prépare le cache pour les internautes (d'où le terme «préchauffage», comme pour un moteur de voiture), plutôt que de laisser le premier visiteur avec un cache miss. Ainsi, tout le monde bénéficie de la même expérience de qualité.

Si le pré-chargement du cache est une technique intéressante, il faut cependant rester vigilant.e.

Voici quelques difficultés que vous pouvez rencontrer lors de la mise en place d’un préchargement du cache.

Trop de serveurs de cache à préchauffer

Si les pages sont mises en cache sur un CDN ayant plusieurs centaines de serveurs edge, le système devra mettre en place tous ces caches. Le site peut utiliser un robot d'indexation ou crawler. Ce robot devra se rendre sur le site Web à plusieurs reprises et à partir de plusieurs emplacements pour s'assurer que chaque cache est rempli.
Dans ce cas, la stratégie la plus raisonnable est de ne cibler que certains nœuds principaux du CDN (origin shield de KeyCDN, regional edge cache de Cloudfront). Cela réduit l’ampleur de la tâche.

Chez Fasterize, les pages sont généralement mises en cache sur la plateforme. Le problème ne se pose donc pas.

Une durée de vie des pages trop courtes

Si la durée de cache est de quelques minutes, la mise en place d’un crawler ne sera pas efficace. Le crawler n’aura pas le temps de parcourir l’ensemble du catalogue que les pages visitées auront déjà expiré.

Dans ce cas de figure, il faudra trouver un compromis : ne précharger que les pages clés du site.

Un serveur d’origine ne pouvant pas tenir la charge d’un crawling régulier

Le passage d’un crawler peut générer une charge non négligeable sur des origines sous-dimensionnées. En effet, le crawler va demander des pages peu chargées ce qui peut induire des requêtes sollicitant fortement la base de données à l’origine.
Dans ce cas, il faut :

  • réduire le nombre de pages crawlées,
  • ou réduire la vitesse de crawling
  • ou encore effectuer un crawling aux heures creuses de la journée.

Trop de variations possibles par page

Si la page produit se décline sous des centaines de versions (une version par magasin physique par exemple), le nombre de pages à traiter peut être trop important par rapport aux temps de crawling alloués. Dans ce cas, il est souhaitable de prioriser les versions pour ne crawler que les versions principales de chaque page.

Comment fonctionne le crawler de Fasterize

Notre crawler a deux modes de fonctionnements :

  • le parcours des URL présentes dans le sitemap du site
  • le parcours d’une liste d’URLs fournies par le client

Le crawler ne prend en compte que les URLs des pages du sitemap. Les URLs des images ne sont pas crawlées. Nous conseillons ce mode en raison de sa simplicité. Cependant, si le sitemap n’est pas exploitable car trop large ou périmé, il est possible de fournir une liste statique d’URLs. Cette liste est alors parcourue du début à la fin.

La vitesse de crawling est paramétrable :

  • le nombre de robots crawlant en parallèle (par défaut 4)
  • le temps d’attente entre chaque requête (par défaut 0.2 sec).

Il est également possible de configurer l’entête User-Agent utilisé par le crawl. Il s’agit par défaut de Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36k FstrzCrawler.

Enfin, les en-têtes de la requête sont elles aussi personnalisables pour plus de flexibilité :

  • adresser plusieurs variations selon le cookie de variation fstrz_vary
  • imposer un rafraîchissement obligatoire ou optionnel de chaque page.
  • rafraîchir plusieurs caches de Fasterize : le cache principal ou le cookieless cache.

Restez informé.e de notre actualité et de nos fonctionnalités,
inscrivez-vous à notre newsletter :

Je m'abonne !

 


Hello SMX Paris !