Pre-Caching dynamisch generierter Bilder für mehrere Edge-Standorte auf Amazon Cloudfront

Question

Wir verwenden derzeit CloudFront in vielen Edge-Standorten, um Produktbilder (fast eine halbe Million) zu liefern, die dynamisch in verschiedene Größenabmessungen geändert werden. Unsere Cloudfront-Distribution verwendet ein originales EC2-PHP-Skript, um das Originalbild aus S3 abzurufen, basierend auf den angegebenen Querystring-Kriterien (Breite, Höhe, Zuschneiden usw.) dynamisch zu transformieren und es an Cloudfront zurückzuspeichern.

Allerdings, Website-Besucher laden ein nicht im Cache gespeichertes Bild das erste Mal durch diese ziemlich schwere Transformation getroffen werden.

Wir hätten gerne die Möglichkeit, unsere Bilder "vorab zu cachen" (indem wir einen Stapeljob verwenden, der jede Bild-URL anfordert), so dass die Endanwender nicht als erste ein Bild in einer bestimmten Größe treffen usw.

Da die Bilder nur an der Edge-Position zwischengespeichert werden, die dem Pre-Caching-Dienst zugewiesen ist, erhalten Websitebesucher, die einen anderen Edge-Speicherort verwenden, das zwischengespeicherte Image nicht und werden mit dem Skript zur Größenänderung auf dem Ursprungsserver angezeigt.

Die einzige Lösung, die wir mit kommen von haben, wo jede Kante Ort ein Bild innerhalb einer angemessenen Ladezeit abrufen kann, ist dies:

Wir haben eine Cloudfront-Distribution, die einen Ursprung EC2 PHP-Skript verweist. Statt die oben beschriebene Bildumwandlung durchzuführen, leitet das Origin-Skript die Parameter für die Anforderung und die Abfragezeichenfolge an eine andere Cloudfront-Verteilung weiter. Diese Distribution hat ein Ursprungs-EC2-PHP-Skript, das die Bildumwandlung durchführt. Auf diese Weise wird das Bild immer an der Edge-Position in der Nähe unserer EC2-Instanz (Irland) zwischengespeichert, wodurch vermieden wird, eine weitere Transformation durchzuführen, wenn das Bild von einer anderen Kantenposition angefordert wird.

So, zum Beispiel, eine Anfrage in Schweden/image/stream/id/12345, die die schwedische Edge Location nicht zwischengespeichert hat, so sendet es eine Anfrage an den Ursprung, der die EC2-Maschine in Irland ist . Die EC2-Seite "streaming" lädt dann/image/size/id/12345 aus einer anderen Cloudfront-Distribution, die den Irish Edge-Standort erreicht, der sie auch nicht zwischengespeichert hat. Es sendet dann eine Anfrage an den Ursprung, wiederum die gleiche EC2-Maschine, aber an die "Größe" -Seite, die die Größenänderung vornimmt. Danach wird das Bild im Edge-Standort in Schweden und in Irland zwischengespeichert.

Jetzt fordert eine Anfrage aus Frankreich das gleiche Bild an. Der französische Edge-Ort hat ihn nicht zwischengespeichert, daher nennt er den Ursprung, den EC2-Rechner in Irland, der die zweite CF-Distribution aufruft, die wiederum den irischen Edge-Standort erreicht. Dieses Mal wird das Bild zwischengespeichert und kann es sofort zurückgeben. Jetzt wird auch das Bild im Cache gespeichert, ohne dass die Seite "Größe ändern" aufgerufen wurde - nur die "Streaming" -Seite mit dem zwischengespeicherten Bild in Irland.

Das bedeutet auch, dass unser ‚Pre-Caching“ Batch-Service in Irland Anfrage gegen die irish Kantenort tun kann und Pre-Cache die Bilder, bevor sie von unseren Website-Besuchern aufgefordert sind.

Wir wissen, es sieht ein bisschen absurd, aber mit dem Wunsch, den Endnutzer sollte nie lange warten, während das Bild in der Größe geändert wird, scheint es wie die einzige greifbare Lösung

Haben wir eine andere/bessere Lösung übersehen? Irgendwelche Kommentare zu den oben genannten?

Answer 1

Ich bin nicht sicher, dass dies Ladezeiten verringern wird (wenn das y war unser Ziel).

Ja, dieses Setup spart einige "Transformationszeit", aber auf der anderen Seite wird dies auch eine zusätzliche Kommunikation zwischen den Servern erstellen.

I.E. Client Anrufe Französisch POP >> Französisch POP Anrufe Irland POP = Doppelte Downloadzeit (und einige), die länger als die "Transformationszeit" sein kann ...

Ich arbeite für Incapsula und wir haben unsere eigenen entwickelt Ein Verhalten, das heuristische Prozesse analysiert, um das dynamische Caching von Inhalten zu behandeln. (Hier kurz dokumentiert: http://www.incapsula.com/the-incapsula-blog/item/414-advanced-caching-dynamic-through-learning)

Unsere Räumlichkeiten sind:

Während eine Webseite Millionen von dynamischen Objekten haben kann, nur einige von denen, unterliegen wiederholte Anfrage.

Nach dieser Logik haben wir einen Algorithmus, der Besuchsmuster lernt, gute "Kandidaten" für Caching findet und diese dann auf einem redundanten Server zwischenspeichert. (wodurch der oben erwähnte "Doppel-Download" vermieden wird)

Der Inhalt wird dann alle 5 Minuten erneut gescannt, um Frische zu bewahren und das heuristische System verfolgt, um sicherzustellen, dass der Inhalt immer noch beliebt ist.

Dies ist eine übermäßig vereinfachte Erklärung, aber es zeigt die Kernidee, die lautet: Finden Sie heraus, was Ihre Benutzer am meisten brauchen. Steigen Sie auf alle POPs ein. Behalten Sie den Überblick, um Frische zu bewahren und Trends zu erkennen.

Hoffe, das hilft.

Answer 2

Nur ein Gedanke ...

Führen Sie zwei Caches.

1. ein an jeder Kantenposition, in Irland
2. Ein auf dem Server (oder ElastiCache wenn mehrere Server). Sie müssen nicht viel länger als ein paar Minuten zwischengespeichert werden.

haben eine Mikro Instanz Daten-Pipeline oder eine Warteschlange,

befestigt läuft, wenn die Anfrage den Ursprungsserver kommt, zurückzukehren und Server-Cache ist das Bild. Legen Sie die URL auch in die Warteschlange.

Dann muss der Daemon mehrere Aufrufe an jede Kantenposition senden. An diesem Punkt wird Ihr Server erneut getroffen (da die anderen Edge-Standorte nicht über das Image verfügen) - aber es wird sofort aus dem Cache bereitgestellt - ohne dass die teure Transformation durchgeführt werden muss.

Wenn es nicht die Transformation tut und nur aus dem Cache dient - sollte keine große Sache sein.

So würde der Fluss wie sein diese

Request -> Cloud Front -> EC2 -> Add to cache -> Response -> CloudFront Cache -> User 
    -      -> Queue new request at each edge location 
Request -> Cloud Front -> EC2 -> already cached -> Response -> CloudFront -> User 

Sie würden eine Form von Marker müssen zu erklären, dass es bereits serviert und zwischengespeichert worden sind, sonst würden Sie in einer Endlosschleife enden.