AWS CloudFront * dovrebbe aumentare * il tempo di caricamento per i file a cui si accede raramente?


9

Sono nuovo di CDN e sto sperimentando CloudFront. Ho impostato tutto e tutto sembra funzionare bene. Posso creare un'immagine statica su una pagina e accedervi tramite la mia distribuzione CloudFront. Sto usando un'origine personalizzata (cioè non un bucket S3).

Sono preoccupato che potrei essere peggio dal punto di vista delle prestazioni. Ho una pagina di prova che sta caricando le stesse circa 20 immagini con e senza CDN. Guardando il pannello di rete in Firebug, la prima volta che carico questa pagina le immagini che vengono caricate direttamente dal server di origine arrivano molto più velocemente. Nella pagina successiva i vantaggi della CDN diventano evidenti: dopo 3-5 aggiornamenti la CDN sta facendo meglio del server di origine.

Quindi posso vedere che su una pagina popolare sul nostro sito che viene colpita continuamente, questo sarà un vantaggio. E dovrei aspettarmi un vantaggio perché sono a Seattle (dietro l'angolo da Amazon) e il mio server è in California.

Il fatto è che se lascio la pagina per alcuni minuti e poi ricarico, le cose tornano al punto di partenza, con CloudFront peggiore del server di origine. È previsto? Le cose escono dalla "cache" della CDN così rapidamente?

È possibile che qualcosa nella mia configurazione stia danneggiando le prestazioni? Oppure la realtà è che la rete CDN sarà positiva solo per i contenuti a cui si accede in media ogni pochi secondi?

(Cross postato dal forum AWS perché sono stato viziato per sempre dai tempi di consegna di SO)

AGGIORNARE:

Di seguito sono riportate due buone risposte che vale la pena esaminare in caso di domande sulle prestazioni di CloudFront. Recentemente ho trovato una spiegazione per il mio problema specifico non è stata menzionata però. Avevo lasciato il TTL a 5 minuti come svista. Dal momento che sto usando anche un'origine personalizzata, c'è un ulteriore round trip per l'autorevole nameserver per risolverlo nell'attuale dominio Amazon CloudFront. Ora che l'impostazione TTL è tornata a 12 ore sembra che i carichi lunghi avvengano più raramente.


Sì, è possibile che CloudFront sia più lento del semplice andare direttamente a un server veloce, perché CloudFront è uno dei CDN più lenti in circolazione, a causa del modo in cui Amazon lo ha implementato con più livelli di risoluzione DNS, ecc. Esegui alcuni benchmark da differnet sedi in tutto il mondo e decidi se è adatto a te oppure no - usa webpagetest.org per i test.
Jesper M,

Risposte:


5

Cloudfront imposta un'intestazione nelle risposte come "X-Cache: Hit from cloudfront" nelle risposte. Presumibilmente, dirà "Miss" se il tuo file non era nella cache del nodo a cui sei stato indirizzato.

È possibile che i tuoi file non siano abbastanza popolari, quindi vengono espulsi dalla cache di CloudFront da contenuti più popolari anche se non sono trascorse 24 ore. È anche possibile che un sovraccarico di I / O o qualche altra circostanza all'interno di un particolare nodo CloudFront rallenti l'accesso. Cloudfront è molto economico rispetto ad Akamai o LimeLight. Prestazioni peggiori e livelli di servizio garantiti sono due dei motivi per utilizzare i giocatori più costosi.

Farei un test, inserendo solo un file popolare nel cloudfront in produzione, e quindi usando test periodici per verificare se CloudFront sta indicando hit (registrando anche il tempo totale della transazione).


Ho aggiornato la domanda con un'altra potenziale spiegazione per il problema perf che ho visto, ovvero che avevo lasciato l'impostazione TTL con un'impostazione bassa di 5 minuti, ma quando torno a 12 ore non penso di vederli occasionali problemi di perf.
Greg,

7

È possibile. Tuttavia, uno scopo di una CDN è la scalabilità. Puoi aspettarti che la CDN esegua lo stesso se lanci 100 visite contemporaneamente o 1 milione di visite contemporaneamente.

Per quanto riguarda la tua configurazione, non c'è nulla che io possa sapere con le informazioni che hai fornito, ma penso che il punto sopra sia ciò che rende una CDN così preziosa. Se stai creando un sito che non riceve molto traffico, potresti stare meglio senza la CDN. Tuttavia, la CDN fornirà un carico più leggero sul tuo server web se ricevi molto traffico perché stai passando la pubblicazione dei tuoi media a un altro server. Un ultimo punto, un buon CDN (e quello di Amazon) useranno la loro vasta rete per servire i tuoi contenuti dalla posizione più vicina al richiedente. In molti casi, possono servire il contenuto dall'ISP del richiedente, il che significa tempi di caricamento MOLTO rapidi.

Spero che aiuti.


Grazie Jesse - molto utile. Il punto relativo al ridimensionamento è ben preso. E disponiamo di traffico sufficiente per fare la differenza. Mi piacerebbe comunque conoscere la politica di memorizzazione nella cache. Ho trovato un'enorme quantità di informazioni su COME impostare il CDN e molto poco sulle sue caratteristiche. Mi chiedo, ad esempio, se dovrei escludere (dalla CDN) i vecchi contenuti a cui si accede molto raramente.
Greg

Greg - Non vedo un argomento per escludere il contenuto, se non forse per motivi finanziari. Puoi, tuttavia, controllare le intestazioni della cache del tuo oggetto in Amazon. Potresti provare a esaminare questo: stackoverflow.com/questions/269840/…
Jesse Bunch

Ciò ti consentirebbe di specificare le intestazioni con scadenza molto futura come faresti con qualsiasi normale supporto di siti Web.
Jesse Bunch,

Grazie ancora. Quel collegamento per il controllo della cache non è rilevante per la mia situazione perché sto usando un server di origine personalizzato, non s3. Ma il principio si applica e ho un set di intestazioni molto scadente. A proposito, i documenti di Amazon affermano che il contenuto rimane nella cache per 24 ore, ma i miei esperimenti indicano qualcosa di diverso.
Greg

1

Ho frainteso? Il controllo della cache non gestisce la durata delle cose nelle posizioni dei bordi prima che le posizioni dei bordi li ricarichino da S3? Quindi sicuramente sono rilevanti per la tua situazione se usi S3 o la tua stessa origine? No?

Le domande frequenti su Amazon indicano: "Per quanto tempo Amazon CloudFront manterrà i miei file nelle posizioni dei bordi? Per impostazione predefinita, se non è impostata alcuna intestazione di controllo della cache, ogni posizione dei bordi verifica la presenza di una versione aggiornata del file ogni volta che riceve una richiesta superiore a 24 ore dopo la volta precedente ha verificato l'origine delle modifiche a quel file, chiamato "periodo di scadenza". Puoi impostare questo periodo di scadenza su 1 ora o quanto vuoi, impostando le intestazioni di controllo della cache sui tuoi file nella tua origine. Amazon CloudFront utilizza queste intestazioni di controllo della cache per determinare con quale frequenza deve controllare il origine per una versione aggiornata di quel file. Se i tuoi file non cambiano molto spesso, è consigliabile impostare un lungo periodo di scadenza e implementare un sistema di controllo delle versioni per gestire gli aggiornamenti dei tuoi file. "

[Suppongo che l'ultima frase significhi "sfortuna se la imposti a 50 anni e poi vuoi cambiare il file".]

Il punto principale dell'utilizzo di una CDN è che ospita contenuto statico? In tal caso, sarebbe utile utilizzare TTL considerevolmente più lungo di un giorno? Praticamente per tutto (tutte le immagini e i CSS), utilizzo Cache-Control = "max-age = 604800, public, must-revalidate" (ovvero 1 settimana). Nella mia esperienza, i file sicuramente impiegano fino a una settimana per cambiare se carico nuove versioni su S3.

Spero che sia di aiuto. [A proposito: sul tuo punto più generale, mi chiedo anche se un CDN aiuta le prestazioni tanto quanto pensi che succederà. Sto per spostare il mio intero sito (CDN inclusa) su un server dedicato superveloce e fare alcuni test per scoprirlo.]


Hai ragione che il controllo della cache influenza per quanto tempo il contenuto viene mantenuto al limite. Il TTL è una questione separata però. TTL controlla la memorizzazione nella cache dell'indirizzo IP assegnato al nome di dominio. Quindi, indipendentemente dal fatto che il file statico sia memorizzato nella cache al limite o meno, la prima volta che un server vede l'URL del file deve trovare l'indirizzo IP di questo dominio. Con 1 giorno di TTL, è probabile che un server vicino abbia queste informazioni nella sua cache DNS. Con un TTL di 5 minuti questo è molto meno probabile ed è necessario un giro completo al mio server di origine (non per il file, ma per risolvere l'URL) ..
Greg

Ah ok grazie. Stavo confondendo il DNS TTL e il controllo della cache :)
Chris W,

1

I motivi per utilizzare la CDN sono se ti aspetti

  • Contenuto statico - aggiornamenti rari o controllati
  • Visto in tutto il mondo
  • Accesso frequente

Il nostro sito Web è accessibile raramente come nel tuo caso, ma abbiamo una configurazione del servizio di monitoraggio che richiede il nostro sito Web in tutto il mondo. Quindi mantiene calde le cache della CDN. Vorrei anche condividere il nostro caso, che è semplice e dimostra la capacità della CDN.

Inoltre, ci aspettiamo un addebito mensile di 2,2 $ anziché 7 $ per il server godaddy (che non può gestire i picchi)

Tempi medi di caricamento della pagina

Distribuzione del tempo medio di caricamento della pagina

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.