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

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.

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).

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.

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.]

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)