Pre-caching immagini generate dinamicamente per più edge location su Amazon Cloudfront

Question

Attualmente stiamo utilizzando CloudFront in molte Edge Location per servire immagini dei prodotti (quasi mezzo milione) che vengono ridimensionate dinamicamente in dimensioni di dimensioni diverse. La nostra distribuzione di Cloudfront utilizza uno script php di origine EC2 per recuperare l'immagine originale da S3, trasformarla dinamicamente in base ai criteri di querystring forniti (larghezza, altezza, ritaglio, ecc.) E riversarla su Cloudfront che la memorizza nella posizione del bordo.

Tuttavia, il visitatore del sito Web che carica un'immagine non memorizzata nella cache la prima volta viene colpito da questa trasformazione piuttosto pesante.

Ci piacerebbe avere la possibilità di "pre-memorizzare" le nostre immagini (utilizzando un lavoro batch che richiede l'URL di ciascuna immagine) in modo che gli utenti finali non siano i primi a colpire un'immagine con una dimensione particolare, ecc.

Sfortunatamente, poiché le immagini vengono memorizzate solo nella posizione Edge assegnata al servizio di pre-cache, i visitatori del sito Web che utilizzano un'altra posizione Edge non otterranno l'immagine memorizzata nella cache e verranno colpiti con il pesante script di ridimensionamento sul server di origine.

L'unica soluzione che siamo arrivati ​​insieme ai, dove ogni bordo Località può recuperare un'immagine entro il tempo di caricamento ragionevole, è questa:

Abbiamo una distribuzione Cloudfront che punta a uno script php origine EC2. Ma invece di eseguire la trasformazione dell'immagine sopra descritta, lo script di origine inoltra i parametri request e querystring a un'altra distribuzione Cloudfront. Questa distribuzione ha uno script php di origine EC2 che esegue la trasformazione dell'immagine. In questo modo, l'immagine viene sempre memorizzata nella posizione Edge vicino alla nostra istanza EC2 (Irlanda), evitando così di eseguire un'altra trasformazione quando l'immagine viene richiesta da un'altra posizione Edge.

Così, ad esempio, una richiesta in Svezia colpisce/image/stream/id/12345, che la posizione Edge svedese non ha memorizzato nella cache, quindi invia una richiesta all'origine, che è la macchina EC2 in Irlanda . La pagina di "streaming" EC2 carica quindi/image/size/id/12345 da un'altra distribuzione di Cloudfront, che colpisce l'Irish Edge Location, che non ha nemmeno la cache. Invia quindi una richiesta all'origine, sempre la stessa macchina EC2, ma alla pagina 'dimensione' che esegue il ridimensionamento. Dopodiché, sia Edge Location in Svezia che in Irlanda hanno l'immagine memorizzata nella cache.

Ora, una richiesta dalla Francia richiede la stessa immagine. French Edge Location non lo ha memorizzato nella cache, quindi chiama l'origine, che è la macchina EC2 in Irlanda, che chiama la seconda distribuzione CF che colpisce ancora l'irlandese Edge Location. Questa volta ha l'immagine memorizzata nella cache e può restituirla immediatamente. Ora la posizione Edge francese ha anche l'immagine memorizzata nella cache, ma senza dover chiamare la pagina 'ridimensionamento' - solo la pagina 'streaming' con l'immagine della cache in Irlanda.

Questo significa anche che la nostra 'pre-caching" Servizio in batch in Irlanda può fare richiesta contro il bordo Località irlandese e pre-cache delle immagini prima che vengano richiesti dai nostri visitatori del sito web.

Sappiamo che sembra un po 'assurdo, ma con il desiderio che abbiamo, che l'utente finale non debba mai aspettare a lungo mentre l'immagine viene ridimensionata, sembra l'unica soluzione tangibile

Abbiamo trascurato un'altra/migliore soluzione? Qualsiasi commento a quanto sopra?

Answer 1

Non sono sicuro che questo diminuirà i tempi di caricamento (se questo era y il nostro obbiettivo).

Sì, questa impostazione salverà un po 'di "tempo di trasformazione", ma d'altra parte creerà anche una comunicazione aggiuntiva tra i server.

I.E. client chiama POP francese >> chiama POP francese Irlanda POP = Per due volte il tempo di download (e un po '), che potrebbe essere più lungo del "tempo di trasformazione" ...

io lavoro per Incapsula e abbiamo effettivamente sviluppato il nostro un comportamento univoco che analizza il processo euristico per gestire il caching del contenuto dinamico. (Brevemente documentato qui: http://www.incapsula.com/the-incapsula-blog/item/414-advanced-caching-dynamic-through-learning)

I nostri locali è:

Mentre un sito web può avere milioni di oggetti dinamici, solo alcuni di questi sono soggetti a ripetute richieste.

Seguendo questa logica, abbiamo un algoritmo che impara modelli di visita, trova buoni "candidati" per la cache e poi li memorizza su server ridondanti. (evitando il suddetto "doppio download")

Il contenuto viene quindi riesaminato ogni 5 minuti, per preservare la freschezza e il sistema euristico tiene traccia, per assicurarsi che il contenuto sia ancora popolare.

Questa è una spiegazione troppo semplificata, ma dimostra l'idea di fondo, ovvero: Scopri di cosa hanno più bisogno i tuoi utenti. Entra in tutti i POP. Tieni traccia di preservare la freschezza e rilevare le tendenze.

Spero che questo aiuti.

Answer 2

Solo un pensiero ...

Esegui due cache.

1. Uno su ogni posizione bordo,
2. Uno sul server (o elasticache se più server) in Irlanda. Non hanno bisogno di essere memorizzati nella cache per molto più di pochi minuti.

Avere un micro istanza in esecuzione attaccato al gasdotto di dati o una coda,

Quando la richiesta arriva al server di origine, tornare e cache del server l'immagine. Lascia anche cadere l'url sulla coda.

Quindi, fare in modo che il daemon effettui più chiamate a ogni posizione del bordo. A questo punto, il tuo server verrà colpito di nuovo (poiché le altre edge location non avranno l'immagine) - ma verrà servito immediatamente fuori dalla cache - senza necessità di eseguire la costosa trasformazione.

Se non sta facendo la trasformazione e serve solo fuori dalla cache, non dovrebbe essere un grosso problema.

Così il flusso sarebbe stato così

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 

avresti bisogno qualche forma di marcatore di affermare che è stato servito e già nella cache, altrimenti si finirebbe in un ciclo infinito.