AWS CloudFront * devrait-il augmenter * le temps de chargement des fichiers rarement consultés?


9

Je suis nouveau sur les CDN et j'expérimente avec CloudFront. J'ai tout mis en place et tout semble bien fonctionner. Je peux créer une image statique sur une page et y accéder via ma distribution CloudFront. J'utilise une origine personnalisée (c'est-à-dire pas un seau s3).

Je crains cependant d'être pire du point de vue des performances. J'ai une page de test qui charge les mêmes 20 images avec et sans le CDN. En regardant le panneau net dans Firebug, la première fois que je charge cette page, les images chargées directement à partir du serveur d'origine arrivent beaucoup plus rapidement. Sur les pages suivantes, les avantages du CDN deviennent évidents - après 3 à 5 rafraîchissements, le CDN se porte mieux que le serveur d'origine.

Je peux donc voir que sur une page populaire de notre site qui est constamment consultée, ce sera un avantage. Et je dois m'attendre à un avantage car je suis à Seattle (au coin d'Amazon) et mon serveur est en CA.

Le fait est que si je laisse la page pendant quelques minutes et que je la recharge, les choses reviennent à la case départ, CloudFront étant pire que le serveur d'origine. Est-ce attendu? Les choses tombent-elles si rapidement du "cache" CDN?

Est-il possible que quelque chose dans ma configuration nuise aux performances? Ou est-ce la réalité que le CDN ne sera qu'un net positif pour le contenu auquel on accède actuellement en moyenne toutes les quelques secondes?

(croix publiée sur le forum AWS parce que j'ai été gâté pour toujours par les délais d'exécution de SO)

MISE À JOUR:

Il y a deux bonnes réponses ci-dessous qui méritent d'être examinées si vous avez des questions sur les performances de CloudFront. J'ai récemment trouvé une explication à mon problème spécifique qui n'a pas été mentionnée cependant. J'avais quitté TTL à 5 minutes en guise d'oubli. Étant donné que j'utilise également une origine personnalisée, il existe un aller-retour supplémentaire vers le serveur de noms faisant autorité pour le résoudre vers le domaine Amazon CloudFront réel. Maintenant que le réglage TTL est revenu à 12 heures, il semble que les longues charges se produisent plus rarement.


Oui, il est possible que CloudFront soit plus lent que d'aller directement à un serveur rapide, car CloudFront est l'un des CDN les plus lents sur le marché, en raison de la façon dont Amazon l'a implémenté avec plusieurs couches de résolution DNS, etc. dans le monde entier et décidez si cela vous convient ou non - utilisez webpagetest.org pour les tests.
Jesper M

Réponses:


5

Cloudfront définit un en-tête dans les réponses comme «X-Cache: Hit from cloudfront» dans les réponses. Vraisemblablement, il dira "Miss" si votre fichier n'était pas dans le cache du nœud vers lequel vous avez été dirigé.

Il est possible que vos fichiers ne soient tout simplement pas assez populaires, ils sont donc éjectés du cache de CloudFront par un contenu plus populaire même si 24 heures ne se sont pas écoulées. Il est également possible qu'une surcharge d'E / S ou toute autre circonstance à l'intérieur d'un nœud CloudFront particulier ralentisse l'accès. Cloudfront est très peu coûteux par rapport à Akamai ou LimeLight. Les pires performances et les niveaux de service garantis sont deux des raisons d'utiliser les joueurs les plus chers.

Je ferais un test, en mettant un seul fichier populaire dans cloudfront en production, puis en utilisant des tests périodiques pour voir si CloudFront indique des hits (enregistrez également le temps total de transaction).


J'ai mis à jour la question avec une autre explication potentielle du problème de perf que j'ai vu, c'est que j'avais laissé le réglage TTL au réglage bas de 5 minutes, mais en revenant à 12 heures, je ne pense pas que je vois ces problèmes de perf occasionnels aussi souvent.
Greg

7

C'est possible. Cependant, l'un des objectifs d'un CDN est l'évolutivité. Vous pouvez vous attendre à ce que le CDN effectue la même chose si vous effectuez 100 visites à la fois ou 1 million de visites à la fois.

En ce qui concerne votre configuration, je ne peux rien savoir des informations que vous avez fournies, mais je pense que le point ci-dessus est ce qui rend un CDN si précieux. Si vous créez un site qui ne reçoit pas beaucoup de trafic, vous pourriez être mieux sans le CDN. Cependant, le CDN fournira une charge plus légère sur votre serveur Web si vous obtenez beaucoup de trafic car vous transférez la diffusion de vos médias vers un autre serveur. Un dernier point, un bon CDN (et celui d'Amazon) utilisera son vaste réseau pour servir votre contenu à partir de l'emplacement le plus proche du demandeur. Dans de nombreux cas, ils peuvent servir le contenu du FAI du demandeur, ce qui signifie des temps de chargement TRÈS rapides.

J'espère que cela pourra aider.


Merci Jesse - très utile. Le point concernant la mise à l'échelle est bien pris. Et nous avons suffisamment de trafic pour que cela fasse une grande différence. J'aimerais toujours connaître la politique de mise en cache. J'ai trouvé énormément d'informations sur COMMENT configurer le CDN et très peu sur ses caractéristiques. Je me demande, par exemple, si je devrais exclure (du CDN) l'ancien contenu auquel on accède très rarement.
Greg

Greg - Je ne vois pas d'argument pour exclure le contenu, sauf peut-être pour des raisons financières. Vous pouvez cependant contrôler les en-têtes de cache de votre objet dans Amazon. Vous pouvez essayer de regarder ceci: stackoverflow.com/questions/269840/…
Jesse Bunch

Cela vous permettrait de spécifier des en-têtes expirant dans un avenir lointain comme vous le feriez avec les médias d'un site Web normal.
Jesse Bunch

Merci encore. Ce lien de contrôle du cache n'est pas pertinent pour ma situation car j'utilise un serveur d'origine personnalisé, pas s3. Mais le principal s'applique et j'ai des en-têtes expirant bien loin. BTW, les documents d'Amazon disent que le contenu vit dans le cache pendant 24 heures, mais mes expériences indiquent quelque chose de différent.
Greg

1

Ai-je mal compris? Le contrôle du cache ne gère-t-il pas la durée de vie des objets aux emplacements périphériques avant que les emplacements périphériques ne les rechargent à partir de S3? Donc, ils sont sûrement pertinents pour votre situation, que vous utilisiez S3 ou votre propre origine? Non?

La FAQ Amazon indique: "Q. Combien de temps Amazon CloudFront conservera-t-il mes fichiers aux emplacements périphériques? Par défaut, si aucun en-tête de contrôle de cache n'est défini, chaque emplacement périphérique recherche une version mise à jour de votre fichier chaque fois qu'il reçoit une demande supérieure à 24 heures après la dernière fois, il a vérifié l'origine des modifications apportées à ce fichier. C'est ce qu'on appelle la «période d'expiration». Vous pouvez définir cette période d'expiration aussi courte que 1 heure, ou aussi longtemps que vous le souhaitez, en définissant les en-têtes de contrôle du cache sur vos fichiers dans votre origine. Amazon CloudFront utilise ces en-têtes de contrôle du cache pour déterminer la fréquence à laquelle il doit vérifier le origine d'une version mise à jour de ce fichier. Si vos fichiers ne changent pas très souvent, il est recommandé de définir une longue période d'expiration et de mettre en œuvre un système de gestion des versions pour gérer les mises à jour de vos fichiers. "

[Je suppose que la dernière phrase signifie "pas de chance si vous la fixez à 50 ans et que vous souhaitez ensuite modifier le fichier".]

N'est-ce pas l'intérêt d'utiliser un CDN qu'il héberge du contenu statique? Dans l'affirmative, cela aiderait-il à utiliser un TTL considérablement plus long qu'un jour? Pour pratiquement tout (toutes les images et CSS), j'utilise Cache-Control = "max-age = 604800, public, must-revalidate" (soit 1 semaine). D'après mon expérience, les fichiers prennent définitivement jusqu'à une semaine pour changer si je télécharge de nouvelles versions sur S3.

J'espère que cela t'aides. [BTW: Sur votre point plus général, je me demande moi aussi si un CDN améliore les performances autant que vous le pensez. Je suis sur le point de déplacer tout mon site (CDN inclus) sur un serveur dédié ultra-rapide et de faire quelques tests pour le découvrir.]


Vous avez raison de dire que le contrôle du cache influence la durée de conservation du contenu en périphérie. Le TTL est une question distincte cependant. TTL contrôle la mise en cache de l'adresse IP attribuée au nom de domaine. Ainsi, que le fichier statique soit mis en cache à la périphérie ou non, la première fois qu'un serveur voit l'URL du fichier, il doit trouver l'adresse IP de ce domaine. Avec TTL 1 jour, il est probable qu'un serveur voisin ait cette information dans son cache DNS. Avec un TTL de 5 minutes, cela est beaucoup moins probable et un aller-retour complet vers mon serveur d'origine est requis (pas pour le fichier, mais pour résoudre l'URL) ..
Greg

Ah ok merci. Je confondais DNS TTL et cache-control :)
Chris W

1

Les raisons d'utiliser CDN sont si vous vous attendez

  • Contenu statique - mises à jour peu fréquentes ou contrôlées
  • Vue dans le monde
  • Consulté fréquemment

Notre site Web est rarement consulté comme votre cas, mais nous avons une configuration de service de surveillance qui demande notre site Web partout dans le monde. Il garde donc les caches CDN au chaud. Je voudrais également partager notre cas qui est simple et démontre la capacité CDN.

De plus, nous nous attendons à des frais mensuels de 2,2 $ au lieu de 7 $ pour le serveur godaddy (qui ne peut pas gérer les surtensions)

Temps de chargement de page moyens

Distribution moyenne du temps de chargement des pages

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.