Riduzione delle prestazioni con Azure CDN?

Question

Ho sperimentato parecchio con CDN di Azure e pensavo di essere a casa al sicuro dopo una corretta installazione utilizzando un ruolo web.

Perché il ruolo web?

Bene, volevo i vantaggi delle intestazioni di compressione e memorizzazione nella cache che non riuscivo a ottenere utilizzando il modo blob normale. E come bonus aggiuntivo; anche il vincolo case-sensitive è stato eliminato.

Basta con la scelta di CDN servire; mentre tutto il contenuto prima era servito dallo stesso dominio, ora servo più o meno tutto il contenuto "statico" da cdn.cuemon.net. In teoria, questo dovrebbe migliorare le prestazioni poiché i browser in parallelo possono diffondere la raccolta di contenuti su domini "multipli" rispetto a un solo dominio.

Purtroppo questo ha portato ad una diminuzione delle prestazioni che credo abbia a che fare con il numero di piani di cottura prima che il contenuto viene servito (utilizzando un comando tracert):

C:\Windows\system32>tracert -d cdn.cuemon.net 

Tracing route to az162766.vo.msecnd.net [94.245.68.160] 
over a maximum of 30 hops: 

    1  1 ms  1 ms  1 ms 192.168.1.1 
    2 21 ms 21 ms 21 ms 87.59.99.217 
    3 30 ms 30 ms 31 ms 62.95.54.124 
    4 30 ms 29 ms 29 ms 194.68.128.181 
    5 30 ms 30 ms 30 ms 207.46.42.44 
    6 83 ms 61 ms 59 ms 207.46.42.7 
    7 65 ms 65 ms 64 ms 207.46.42.13 
    8 65 ms 67 ms 74 ms 213.199.152.186 
    9 65 ms 65 ms 64 ms 94.245.68.160 

C:\Windows\system32>tracert cdn.cuemon.net 

Tracing route to az162766.vo.msecnd.net [94.245.68.160] 
over a maximum of 30 hops: 

    1  1 ms  1 ms  1 ms 192.168.1.1 
    2 21 ms 22 ms 20 ms ge-1-1-0-1104.hlgnqu1.dk.ip.tdc.net [87.59.99.217] 
    3 29 ms 30 ms 30 ms ae1.tg4-peer1.sto.se.ip.tdc.net [62.95.54.124] 
    4 30 ms 30 ms 29 ms netnod-ix-ge-b-sth-1500.microsoft.com [194.68.128.181] 
    5 45 ms 45 ms 46 ms ge-3-0-0-0.ams-64cb-1a.ntwk.msn.net [207.46.42.10] 
    6 87 ms 59 ms 59 ms xe-3-2-0-0.fra-96cbe-1a.ntwk.msn.net [207.46.42.50] 
    7 68 ms 65 ms 65 ms xe-0-1-0-0.zrh-96cbe-1b.ntwk.msn.net [207.46.42.13] 
    8 65 ms 70 ms 74 ms 10gigabitethernet5-1.zrh-xmx-edgcom-1b.ntwk.msn.net [213.199.152.186] 
    9 65 ms 65 ms 65 ms cds29.zrh9.msecn.net [94.245.68.160] 

Come si può vedere dalla traccia sopra percorso, tutti i contenuti esterni sono in ritardo per un po 'di tempo. Vale la pena notare che il servizio di Azure è impostato nel Nord Europa e che mi sono stabilito in Danimarca, perché questa via di traccia è un po '.. hmm .. sopra le righe?

Un altro numero potrebbe essere che il ruolo Web sia costituito da due istanze extra piccole; Non ho ancora trovato il tempo di provare con due piccole istanze, ma so che Microsoft limita le istanze extra piccole a una WAN a 5 Mb/s dove piccole e superiori hanno 100 Mb/s.

Non sono sicuro se questo vale anche per CDN.

In ogni caso, qualsiasi aiuto e/o spiegazione è molto apprezzato.

E lasciatemi dire che sono molto soddisfatto della piattaforma Azure - Sono solo curioso riguardo alle questioni di cui sopra.

Aggiornamento

Nuovo tracert senza l'opzione -d.

Essere ispirati da user728584 Ho ricercato e trovato questo articolo, http://blogs.msdn.com/b/scicoria/archive/2011/03/11/taking-advantage-of-windows-azure-cdn-and-dynamic-pages-in-asp-net-caching-content-from-hosted-services.aspx, che mi indagare ulteriormente per quanto riguarda il controllo della cache pubblico e CDN.

Questo non spiega il fenomeno del numero eccessivo di hop, ma spero che un esperto operatore di rete possa aiutare a gettare luce su questo argomento.

Ti assicuriamo che ti terrò aggiornato secondo le mie conclusioni.

Answer 1

Non per dichiarare l'ovvio, ma presumo che tu abbia impostato l'intestazione HTTP Cache-Control su un numero elevato in modo che il tuo contenuto non venga rimosso dalla cache CDN e servito da Blob Storage quando hai eseguito i test tracert?

ci sono un bel paio di server perimetrali vicino a te così mi aspetterei di svolgere meglio: 'Windows Azure CDN Nodo Locations' http://msdn.microsoft.com/en-us/library/windowsazure/gg680302.aspx

Maarten Balliauw ha un grande articolo sui casi di utilizzo e di utilizzo per il CDN (questo potrebbe aiutare):? http://acloudyplace.com/2012/04/using-the-windows-azure-content-delivery-network/

Non sono sicuro se questo aiuta a tutti, interessante ...

Answer 2

Va bene, dopo che avevo implementato pubblici caching-controllo intestazioni, il CDN sembra di fare ciò che ci si aspetta; consegna del contenuto dal numero x dei nodi nel cluster CDN.

Quanto sopra ha il limite che è vissuto - non è misurato per una convalida concreta.

Tuttavia, questo link supporta la mia teoria: http://msdn.microsoft.com/en-us/wazplatformtrainingcourse_windowsazurecdn_topic3,

Il time-to-live (TTL) per i controlli blob per quanto tempo un server perimetrale CDN restituisce una copia della risorsa in cache prima di richiedere una nuova copia dalla sua origine nello storage blob. Una volta scaduto questo periodo, una nuova richiesta imporrà al server CDN di recuperare nuovamente la risorsa dal blob originale, a quel punto lo memorizzerà nuovamente nella cache.

Quale era la mia supposta sfida; le risorse di riferimento CDN continuavano a raggruppare il blob originale.

Inoltre, i crediti devono essere forniti anche a questo collegamento (fornito dall'utente728584); http://blogs.msdn.com/b/scicoria/archive/2011/03/11/taking-advantage-of-windows-azure-cdn-and-dynamic-pages-in-asp-net-caching-content-from-hosted-services.aspx.

E l'ultimo anello, per ora: http://blogs.msdn.com/b/windowsazure/archive/2011/03/18/best-practices-for-the-windows-azure-content-delivery-network.aspx

Per le pagine ASP.NET, il comportamento predefinito è quello di impostare il controllo della cache a privati ​​. In questo caso, , il CDN di Windows Azure non memorizzerà nella cache questo contenuto. Per eseguire l'override di questo comportamento, utilizzare l'oggetto Response per modificare le impostazioni di controllo della cache predefinite.

Quindi la mia conclusione finora per questo piccolo enigma è che devi prestare molta attenzione al tuo controllo della cache (che spesso è impostato su privato per ovvi motivi). Se salti l'approccio del ruolo web, il TTL è per impostazione predefinita di 72 ore, perché potresti non sperimentare mai ciò che ho vissuto; quindi funzionerà appena fuori dalla scatola.

Grazie a user728584 per avermi indicato nella giusta direzione.