Che cosa è utile per TTL 0 in CloudFront?

Question

Qualche settimana fa Amazon ha annunciato di aver abbassato il periodo di scadenza del contenuto:

Amazon CloudFront Lowers Minimum Content Expiration Period

Così tanto che si può effettivamente impostare ora TTL in CloudFront a 0. Quindi la mia domanda è, perché potrebbe essere utile avere una distribuzione CloudFront con TTL impostato su 0. Per me questo significa nessuna memorizzazione nella cache, quindi ogni richiesta che arriva a CloudFront finirà per colpire l'origine.

Cosa mi manca?

Answer 1

Questa nuova funzione di Amazon CloudFront è in realtà estremamente utile per molti casi d'uso, perché colpendo l'origine funziona un po 'diverso di quanto sembri a prima vista e non è necessariamente un problema, al contrario; mentre questa funzione è già stata rilasciata in precedenza, viene fornita insieme alla recente versione di Amazon CloudFront - Support for Dynamic Content, ad es. per la questione a portata di mano:

variabile Time-To-Live (TTL) - In molti casi, il contenuto dinamico è o non memorizzabile nella cache o cacheable per un brevissimo periodo di tempo, forse solo alcuni secondi. In passato, il TTL minimo di CloudFront era di 60 minuti poiché tutto il contenuto era considerato statico. Il nuovo valore minimo TTL è 0 secondi. Se si imposta il TTL per una particolare origine su 0, CloudFront memorizzerà comunque il contenuto del contenuto di da tale origine. Sarà quindi effettuare una richiesta GET con un If-Modified-Since, dando così l'origine la possibilità di segnale che CloudFront può continuare ad utilizzare il contenuto memorizzato nella cache se non è cambiato all'origine. [sottolineatura mia]

In altre parole, usando un TTL di 0 significa in primo luogo, che i delegati CloudFront l'autorità per il controllo della cache l'origine, vale a dire il server di origine decide se o no, e se per quanto tempo CloudFront memorizza nella cache gli oggetti; Si prega di notare in particolare, che una richiesta GET con un If-Modified-Since non significa necessariamente che l'oggetto stesso viene recuperato dall'origine, piuttosto l'origine può (e dovrebbe) restituire il HTTP status code 304 - Not Modified se del caso:

Indica che la risorsa non è stata modificata dall'ultima richiesta. [...] Utilizzando questo consente di risparmiare larghezza di banda e la rielaborazione sia sul server e cliente, come solo i dati di intestazione devono essere inviati e ricevuti in rispetto alla totalità della pagina in fase di ri-elaborati dal server , quindi inviato di nuovo utilizzando più larghezza di banda del server e del client. [sottolineatura mia] di eccellente Caching Tutorial per i dettagli sulla meccanica e benefici di controllo della cache HTTP, una parte molto importante ed efficace dell'architettura HTTP

See Mark Nottingham.

Capire come tutte queste parti lavorano insieme può essere un po 'difficile in effetti, di conseguenza tabella della sezione Specificare il tempo minimo che CloudFront Caches Oggetti per il download Distribuzioni all'interno Specifying How Long Objects Stay in a CloudFront Edge Cache (Object Expiration) tentativi di riassumere gli effetti quando applicata nel contesto di CloudFront con o senza TTL = 0 in particolare.

Answer 2

Nota che Amazon non sta dicendo "TTL è 0", sta dicendo "Minimum TTL is 0". e questo è molto diverso. La descrizione di cui sopra è molto desiderabile ma non vi è alcuna garanzia che Cloudfront lo faccia effettivamente.

Nelle mie esperienze in questo momento, posso vedere un'immagine in cache rimanere per qualche minuto sul bordo mentre la mia origine ha già cambiato.

Quindi, penso che "Il TTL minimo è 0" è probabilmente più simile a "Amazon non ha alcun intento rigido di mantenere questo in una cache", e forse "e si rifarà spesso".

Per applicazioni come CMS, in cui l'utente Web sta pubblicando nuovi contenuti, penso che TTL-0 non sia ancora sufficiente. Devi ancora invocare invalidi dal CMS o impiegare percorsi diversi per numeri di versione diversi.