Comment réduire la latence des réponses lentes de CloudFront ?

Date de la dernière mise à jour : 28/08/2020

J'observe une latence élevée lorsque des objets ou des images sont téléchargés depuis Amazon CloudFront. Les requêtes qui reçoivent la réponse « X-Cache: Miss from cloudfront » sont plus lentes à charger que les requêtes qui reçoivent la réponse « X-Cache: Hit from cloudfront ». Pourquoi cela se produit-il ? Comment résoudre ce problème ? 

Solution

CloudFront renvoie « X-Cache: Miss from cloudfront » lorsque la requête est envoyée vers l'origine. CloudFront renvoie « X-Cache: Hit from cloudfront » lorsque les requêtes sont fournies depuis l'emplacement périphérique le plus proche. Les requêtes « Miss » peuvent être plus lentes à charger en raison de l'étape supplémentaire de transfert vers l'origine.

Pour éviter le transfert des requêtes vers l'origine en raison des problèmes de latence, vérifiez les éléments suivants pour vous assurer que les requêtes peuvent être fournies depuis les emplacements périphériques CloudFront :

  • Ne transférez pas tous les en-têtes, tous les cookies, ni toutes les chaînes de requête, car cela amène CloudFront à transférer directement les requêtes au lieu de les mettre en cache.
  • Vérifiez que vous avez des comportements de cache distincts pour le contenu statique (par exemple, les fichiers CSS) qui change rarement, et pour le contenu dynamique (par exemple, les fichiers JavaScript) qui change souvent. Pour le contenu statique, évitez la mise en cache basée sur des cookies, des chaînes de requête ou des en-têtes qui ne sont à l'origine pas nécessaires pour diffuser le contenu.
    Remarque : pour les distributions web, par défaut, CloudFront ne prend pas en compte les cookies lors de la mise en cache des objets dans des emplacements périphériques. Si votre origine renvoie deux objets qui diffèrent uniquement par les valeurs de l'en-tête Set-Cookie, CloudFront met en cache une seule version de l'objet.
  • Augmentez la valeur des paramètres Minimum TTL, Maximum TTL ou Default TTL pour les modèles de chemin nécessitant davantage de temps en cache avant que CloudFront n’interroge l’origine.
  • Si votre origine utilise des en-têtes Cache-Control, vérifiez que les directives sont compatibles avec les valeurs des paramètres Minimum TTL, Maximum TTL ou Default TTL définies sur la distribution.
  • Si votre origine utilise l'en-tête Expires, vérifiez que ce dernier permet à CloudFront de mettre en cache les réponses si nécessaire.
  • Vérifiez que votre serveur d'origine définit des valeurs valides et exactes pour les champs d’en-tête Date et Last-Modified (Dernière modification).
  • Limitez l'utilisation des invalidations sur les objets. Exécutez les invalidations uniquement lorsque cela est nécessaire.
  • Vérifiez la fréquence des requêtes effectuées sur les objets. Si un objet n'est pas la cible de requêtes fréquentes, CloudFront peut supprimer cet objet d'un emplacement périphérique.

Si vous diffusez du contenu dynamique et si vous pensez que vos requêtes vous renverront des réponses « X-Cache:Miss from cloudfront », envisagez les moyens suivants pour réduire la latence de ces requêtes sans utiliser la mise en cache :

  • Configurez plus de serveurs d'origine géographiquement plus proches de vos demandeurs. Ensuite, configurez un seul enregistrement DNS de routage basé sur la latence (par exemple, origin-latencybased-dnsrecord.example.com) qui se répartit entre ces serveurs. Dans CloudFront, configurez le nom DNS (par exemple, origin-latencybased-dnsrecord.example.com) comme origine de votre distribution. Cette configuration permet à CloudFront d'extraire le contenu du serveur d'origine avec la latence la plus faible en fonction de l'emplacement périphérique sur lequel la requête se trouve. Si vous utilisez Amazon Route 53 comme fournisseur DNS, consultez l'article Ajout d'une autre région à votre routage basé sur la latence dans Amazon Route 53.
  • Augmentez le délai d'inactivité Keep-alive pour votre origine CloudFront. Cette valeur spécifie la durée pendant laquelle CloudFront maintient une connexion inactive avec votre serveur d'origine avant de la couper. Le délai d'inactivité Keep-alive par défaut est de cinq secondes, mais vous pouvez définir une valeur allant jusqu'à 60 secondes si vos serveurs d'origine le permettent. Si votre distribution transmet les demandes de contenu dynamique à l'origine, l'augmentation de la valeur du délai d'inactivité peut contribuer à réduire la latence, car CloudFront n'a pas besoin de créer une nouvelle connexion pour chaque requête.
    Remarque : une origine peut avoir plusieurs adresses IP. Pour utiliser des connexions persistantes sur plusieurs adresses IP d'origine, CloudFront s'appuie sur un taux de demande plus élevé et une fréquence accrue des demandes. Cela est dû au fait que les demandes sont routées autour des adresses IP d'origine et que les connexions sont conservées pour chaque adresse.