Sollte AWS CloudFront die Ladezeit für Dateien, auf die selten zugegriffen wird, * verlängern *?

Ich bin neu in CDNs und experimentiere mit CloudFront. Ich habe alles eingerichtet und alles scheint gut zu funktionieren. Ich kann ein statisches Bild auf einer Seite erstellen und über meine CloudFront-Distribution darauf zugreifen. Ich verwende einen benutzerdefinierten Ursprung (dh keinen S3-Bucket).

Ich mache mir allerdings Sorgen, dass es mir aus Sicht der Leistung schlechter geht. Ich habe eine Testseite, auf der ungefähr 20 Bilder mit und ohne CDN geladen werden. Wenn ich mir das Net Panel in Firebug anschaue, kommen die Bilder, die direkt vom Ursprungsserver geladen werden, beim ersten Laden dieser Seite viel schneller an. Beim Laden der nachfolgenden Seite werden die Vorteile des CDN deutlich - nach 3-5 Aktualisierungen ist das CDN besser als der Ursprungsserver.

Ich kann also sehen, dass dies auf einer beliebten Seite unserer Website, die ständig aufgerufen wird, von Vorteil ist. Und ich sollte einen Vorteil erwarten, weil ich in Seattle (um die Ecke von Amazon) bin und mein Server in CA ist.

Die Sache ist, dass, wenn ich die Seite für ein paar Minuten verlasse und dann neu lade, die Dinge wieder auf dem ersten Platz sind, wobei CloudFront schlechter ist als der Ursprungsserver. Wird das erwartet? Fallen Dinge so schnell aus dem CDN- "Cache"?

Ist es möglich, dass etwas in meinem Setup die Leistung beeinträchtigt? Oder ist die Realität, dass das CDN nur für Inhalte positiv ist, auf die derzeit durchschnittlich alle paar Sekunden zugegriffen wird?

(Cross aus dem AWS-Forum gepostet, weil ich durch die Turnaround-Zeiten von SO für immer verwöhnt worden bin)

AKTUALISIEREN:

Im Folgenden finden Sie zwei gute Antworten, die Sie sich ansehen sollten, wenn Sie Fragen zur CloudFront-Leistung haben. Ich habe kürzlich eine Erklärung für mein spezifisches Problem gefunden, die jedoch nicht erwähnt wurde. Ich hatte TTL nach 5 Minuten als Versehen verlassen. Da ich auch einen benutzerdefinierten Ursprung verwende, gibt es einen zusätzlichen Roundtrip zum autorisierenden Nameserver, um diesen in die eigentliche Amazon CloudFront-Domain aufzulösen. Jetzt, da die TTL-Einstellung wieder auf 12 Stunden eingestellt ist, scheinen die langen Lasten seltener aufzutreten.

Cloudfront setzt einen Header in Antworten wie "X-Cache: Hit from Cloudfront" in Antworten. Vermutlich wird "Miss" angezeigt, wenn sich Ihre Datei nicht im Cache des Knotens befindet, an den Sie weitergeleitet wurden.

Es ist möglich, dass Ihre Dateien einfach nicht populär genug sind, sodass sie von populäreren Inhalten aus dem CloudFront-Cache ausgeworfen werden, obwohl noch keine 24 Stunden vergangen sind. Es ist auch möglich, dass eine E / A-Überlastung oder ein anderer Umstand innerhalb eines bestimmten CloudFront-Knotens den Zugriff verlangsamt. Cloudfront ist im Vergleich zu Akamai oder LimeLight sehr kostengünstig. Die schlechteste Leistung und garantierte Service-Levels sind zwei der Gründe, die teureren Player zu verwenden.

Ich würde einen Test durchführen, bei dem nur eine beliebte Datei in die Cloudfront in der Produktion gestellt wird, und dann regelmäßige Tests verwenden, um festzustellen, ob CloudFront Treffer anzeigt (auch die gesamte Transaktionszeit aufzeichnen).

Es ist möglich. Ein Zweck eines CDN ist jedoch die Skalierbarkeit. Sie können davon ausgehen, dass das CDN dieselbe Leistung erbringt, wenn Sie 100 Besuche gleichzeitig oder 1 Million Besuche gleichzeitig durchführen.

Was Ihr Setup angeht, kann ich mit den von Ihnen bereitgestellten Informationen nichts wissen, aber ich denke, dass der obige Punkt das ist, was ein CDN so wertvoll macht. Wenn Sie eine Site erstellen, die nicht viel Verkehr hat, sind Sie ohne das CDN möglicherweise besser dran. Das CDN entlastet Ihren Webserver jedoch weniger, wenn Sie viel Verkehr haben, weil Sie die Bereitstellung Ihrer Medien an einen anderen Server weitergeben. Ein letzter Punkt: Ein gutes CDN (und das von Amazon) nutzt sein umfangreiches Netzwerk, um Ihre Inhalte von dem Ort aus bereitzustellen, der dem Anforderer am nächsten liegt. In vielen Fällen können sie den Inhalt vom ISP des Anforderers bereitstellen, was SEHR schnelle Ladezeiten bedeutet.

Ich hoffe, das hilft.

Habe ich falsch verstanden? Verwaltet die Cache-Steuerung nicht, wie lange Dinge an den Randpositionen leben, bevor die Randpositionen sie aus S3 neu laden? Sie sind also sicherlich relevant für Ihre Situation, egal ob Sie S3 oder Ihre eigene Herkunft verwenden? Nein?

In den häufig gestellten Fragen zu Amazon heißt es: "F. Wie lange hält Amazon CloudFront meine Dateien an den Randpositionen? Wenn kein Header für die Cache-Steuerung festgelegt ist, sucht jeder Kantenspeicherort standardmäßig nach einer aktualisierten Version Ihrer Datei, wenn eine Anforderung mehr als eingeht 24 Stunden nach dem vorherigen Mal wurde der Ursprung auf Änderungen an dieser Datei überprüft. Dies wird als "Ablaufzeitraum" bezeichnet. Sie können diesen Ablaufzeitraum auf 1 Stunde oder so lange festlegen, wie Sie möchten, indem Sie die Cache-Steuerelement-Header für Ihre Dateien in Ihrem Ursprung festlegen. Amazon CloudFront verwendet diese Cache-Steuerelement-Header, um zu bestimmen, wie häufig die Überprüfung erforderlich ist Ursprung für eine aktualisierte Version dieser Datei. Wenn sich Ihre Dateien nicht sehr oft ändern, empfiehlt es sich, einen langen Ablaufzeitraum festzulegen und ein Versionsverwaltungssystem zu implementieren, um Aktualisierungen Ihrer Dateien zu verwalten. "

[Ich nehme an, der letzte Satz bedeutet "Pech, wenn Sie ihn auf 50 Jahre einstellen und dann die Datei ändern möchten".]

Ist es nicht der Hauptgrund für die Verwendung eines CDN, statische Inhalte zu hosten? Wenn ja, würde es helfen, erheblich längeres TTL als einen Tag zu verwenden? Für praktisch alles (alle Bilder und CSS) verwende ich Cache-Control = "max-age = 604800, public, must-revalidate" (dh 1 Woche). Nach meiner Erfahrung dauert es definitiv bis zu einer Woche, bis sich die Dateien ändern, wenn ich neue Versionen auf S3 hochlade.

Hoffe das hilft. [Übrigens: In Ihrem allgemeineren Punkt frage ich mich auch, ob ein CDN die Leistung so sehr unterstützt, wie Sie denken. Ich bin dabei, meine gesamte Site (einschließlich CDN) auf einen superschnellen dedizierten Server zu verschieben und einige Tests durchzuführen, um dies herauszufinden.]

Die Gründe für die Verwendung von CDN sind, wenn Sie erwarten

• Statischer Inhalt - seltene oder kontrollierte Updates
• Über die Welt gesehen
• Häufiger Zugriff

Auf Ihre Website wird in Ihrem Fall nur selten zugegriffen, aber wir haben einen Überwachungsservice eingerichtet, der unsere Website auf der ganzen Welt anfordert. So bleiben CDN-Caches warm. Ich möchte auch unseren Fall teilen, der einfach ist und die CDN-Fähigkeit demonstriert.

Darüber hinaus erwarten wir eine monatliche Gebühr von 2,2 $ im Gegensatz zu 7 $ für Godaddy-Server (die keine Überspannungen bewältigen können).