web-dev-qa-db-fra.com

Amazon CloudFront Latency

J'expérimente avec AWS S3 et CloudFront pour une application Web que je développe. 

Dans l'application, je laisse les utilisateurs télécharger des fichiers dans le compartiment S3 (à l'aide du kit AWS SDK) et les rendre disponibles via CloudFront CDN. Toutefois, le problème persiste lorsque les fichiers sont chargés et prêts dans le compartiment S3. Cela prend environ une minute ou 2 être disponible dans l'URL de CloudFront CDN, est-ce normal?

amazon-web-servicesamazon-s3amazon-cloudfront
22
Ahsan

CloudFront tente d'extraire en temps réel le contenu non mis en cache du serveur Origin. Il n'y a pas de "délai de réplication" ou de problème similaire car CloudFront est un CDN à extraction directe. Chaque emplacement CloudFront Edge ne connaît que l'existence et la configuration de votre site. il ne connaît pas votre contenu tant qu'il n'a pas reçu de demandes. Lorsque cela se produit, CloudFront Edge extrait le contenu demandé du serveur d'origine et le met en cache, le cas échéant, pour répondre aux demandes suivantes. 

Le problème qui se pose ici est lié à un concept parfois appelé "mise en cache négative" - ​​le fait de mettre en cache le fait qu'une requête ne fonctionnera pas - ce qui est généralement fait pour éviter de marteler l'origine de tout ce qui est mis en cache avec des requêtes qui: sont susceptibles d'échouer de toute façon.

Par défaut, lorsque votre origine renvoie un code de statut HTTP 4xx ou 5xx, CloudFront met en cache ces réponses d'erreur pendant cinq minutes, puis soumet la demande suivante d'objet à votre origine pour voir si le problème à l'origine de l'erreur a été résolu objet est maintenant disponible.

- http://docs.aws.Amazon.com/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html

Si le navigateur, ou toute autre solution, tente de télécharger le fichier à partir de ce CloudFront Edge avant la fin du téléchargement dans S3, S3 renverra une erreur et CloudFront - à cet emplacement Edge - mettra en cache cette erreur et se souviendra de les 5 prochaines minutes, pour ne pas essayer à nouveau.

Ne vous inquiétez pas, ce minuteur est configurable. Par conséquent, si le navigateur le fait sous le capot et en dehors de votre contrôle, vous devriez toujours pouvoir le réparer.

Vous pouvez spécifier la durée de la mise en cache des erreurs (Error Caching Minimum TTL) pour chaque code de statut 4xx et 5xx mis en cache par CloudFront. Pour une procédure, voir Configuration du comportement de réponse d'erreur .

- http://docs.aws.Amazon.com/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html

Pour le configurer dans la console: 

  • Lorsque vous affichez la configuration de la distribution, cliquez sur l'onglet Error Pages. 

  • Pour chaque erreur où vous souhaitez personnaliser le minutage, commencez par cliquer sur Create Custom Error Response.

  • Choisissez le code d'erreur que vous souhaitez modifier dans la liste déroulante, tel que 403 (interdit) ou 404 (introuvable): la configuration de votre compartiment détermine le code renvoyé par S3 pour les objets manquants. Si vous n'êtes pas sûr, modifiez-le. 403 puis répétez le processus et changez 404. 

  • Définissez Error Caching Minimum TTL (seconds) sur 0

  • Laissez Customize Error Response défini sur No (si défini sur Yes, cette option active le contenu de la réponse personnalisée en cas d'erreur, ce qui n'est pas ce que vous souhaitez. L'activation de cette option n'entre pas dans le champ de cette question.)

  • Cliquez sur Create. Cela vous ramène à la vue précédente, où vous verrez Error Caching Minimum TTL pour le code que vous venez de définir. 

Répétez ces étapes pour chaque code de réponse HTTP que vous souhaitez modifier par rapport au comportement par défaut (qui correspond au temps de maintien de 300 secondes, décrit ci-dessus).

Lorsque vous avez apporté toutes les modifications souhaitées, retournez à l'écran principal de la console CloudFront où les distributions sont répertoriées. Attendez que l'état de la distribution passe de In Progress à Deployed (généralement environ 20 minutes pour que les modifications soient répercutées sur toutes les arêtes) et testez. 

35
Michael - sqlbot

Ces nouveaux fichiers sont-ils écrits pour la première fois dans S3 ou sont-ils des mises à jour de fichiers existants? S3 assure la cohérence lecture/écriture pour les nouveaux objets. Compte tenu du modèle d'extraction de CloudFront, vous ne devriez pas rencontrer ce problème avec les nouveaux fichiers écrits dans S3. Si vous l'êtes, j'ouvrirais un ticket avec AWS. 

S'il s'agit de mises à jour de fichiers existants, vous devez gérer la cohérence éventuelle S3 et l'expiration du cache CloudFront. Ce qui pourrait causer ce genre de comportement.

3
Mark B

Comme observé dans votre commentaire, il semblerait que Google Chrome soit en train de gâcher votre stratégie d'envoi/aperçu:

  1. Chrome demande l'URL qui ne contient pas actuellement le contenu
  2. la demande est mise en cache par cloudfront avec une réponse non valide
  3. vous téléchargez le fichier sur S3
  4. lors de la prévisualisation du fichier téléchargé, Cloudfront répond avec la réponse mise en cache (étape 2).
  5. une fois le cache cloudfront expiré, cloudfront atteint Origin et le problème ne peut plus être reproduit. 
0
Alessandro Oliveira