Amazon CloudFront Latenza

Sto sperimentando con AWS S3 e CloudFront per un’applicazione web che sto sviluppando.

Nell’app permetto agli utenti di caricare i file nel secchio S3 (utilizzando l’SDK AWS) e di renderli disponibili tramite CloudFront CDN, ma il problema si verifica anche quando i file vengono caricati e pronti nel secchio S3. Ci vuole circa un minuto o 2 per essere disponibile nell’URL di CloudFront CDN, è normale?

CloudFront tenta di recuperare contenuti non collegati dal server di origine in tempo reale. Non esiste un “ritardo di replica” o un problema simile perché CloudFront è un CDN pull-through. Ogni posizione edge di CloudFront conosce solo l’esistenza e la configurazione del tuo sito; non sa del tuo contenuto finché non riceve richieste per questo. Quando ciò accade, il bordo CloudFront preleva il contenuto richiesto dal server di origine e lo memorizza nella cache in modo appropriato, per servire le richieste successive.

Il problema che si sta verificando qui è legato a un concetto a volte chiamato “cache negativa” – memorizzando nella cache il fatto che una richiesta non funzionerà – che viene in genere eseguita per evitare di martellare l’origine di ciò che viene memorizzato nella cache con richieste che potrebbero fallire Comunque.

Per impostazione predefinita, quando l’origine restituisce un codice di stato HTTP 4xx o 5xx, CloudFront memorizza nella cache queste risposte di errore per cinque minuti e quindi invia la successiva richiesta per l’object all’origine per vedere se il problema che ha causato l’errore è stato risolto e la richiesta l’object è ora disponibile.

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html

Se il browser, o qualsiasi altra cosa, tenta di scaricare il file da quel particolare bordo CloudFront prima che il caricamento in S3 sia completo, S3 restituirà un errore e CloudFront – in quella posizione periferica – memorizzerà l’errore nella cache e ricorderà, per i prossimi 5 minuti, non preoccuparti di riprovare.

Non c’è da preoccuparsi, però – questo timer è configurabile, quindi se il browser sta facendo questo sotto il cofano e fuori dal tuo controllo, dovresti comunque essere in grado di risolverlo.

È ansible specificare la durata del caching degli errori, il TTL minimo di caching degli errori, per ciascun codice di stato 4xx e 5xx che CloudFront memorizza nella cache. Per una procedura, consultare Configurazione del comportamento di risposta agli errori .

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html


Per configurare questo nella console :

  • Quando si visualizza la configurazione di distribuzione, fare clic sulla scheda Error Pages .

  • Per ogni errore in cui si desidera personalizzare la tempistica, iniziare facendo clic Create Custom Error Response .

  • Scegli il codice di errore che desideri modificare dall’elenco a discesa, come 403 (Proibito) o 404 (Non trovato): la configurazione del tuo bucket determina quale codice S3 restituisce per gli oggetti mancanti, quindi se non sei sicuro, cambia 403 quindi ripetere il processo e modificare 404.

  • Imposta Error Caching Minimum TTL (seconds) su 0

  • Lascia Customize Error Response impostato su No (se impostato su Yes , questa opzione abilita il contenuto di risposta personalizzato sugli errori, che non è quello che desideri.L’triggerszione di questa opzione esula dallo scopo di questa domanda).

  • Fai clic su Create . Questo ti riporta alla vista precedente, dove vedrai Error Caching Minimum TTL per il codice appena definito.

Ripetere questi passaggi per ogni codice di risposta HTTP che si desidera modificare dal comportamento predefinito (che è il tempo di attesa di 300 secondi, discusso sopra).

Quando hai apportato tutte le modifiche desiderate, torna alla schermata principale della console di CloudFront in cui sono elencate le distribuzioni. Attendere che lo stato della distribuzione cambi da In Progress a Deployed (in genere circa 20 minuti per le modifiche da inviare a tutti i bordi) e test.

Questi nuovi file vengono scritti su S3 per la prima volta o sono aggiornamenti di file esistenti? S3 fornisce consistenza read-after-write per i nuovi oggetti, e dato il modello pull di CloudFront non dovresti avere questo problema con i nuovi file scritti su S3. Se lo sei, quindi vorrei aprire un biglietto con AWS.

Se si tratta di aggiornamenti a file esistenti, si avrà sia la coerenza finale S3 sia la scadenza della cache CloudFront da gestire. Entrambi potrebbero causare questo tipo di comportamento.

Come osservato nel tuo commento, Google Chrome sembra incasinare la tua strategia di caricamento / anteprima:

  1. Chrome richiede l’URL che attualmente non ha il contenuto.
  2. la richiesta viene memorizzata nella cache da cloudfront con una risposta non valida
  3. si carica il file su S3
  4. quando viene visualizzata l’anteprima del file caricato, il cloudfront risponde con la risposta memorizzata nella cache (passaggio 2).
  5. dopo che la cache del cloudfront è scaduta, il cloudfront raggiunge l’origine e il problema non può più essere riproducibile.