Strategia per ridurre i costi dei dati in uscita di archiviazione di Azure

Question

Sto costruendo un sito Web che (tra le altre cose) consente all'utente di caricare foto tramite web api. Le immagini dell'utente verranno archiviate in BLOB di archiviazione blu per essere visualizzate negli album degli utenti e condivise con i social media. Il sito sarà ospitato come un sito Web azzurro. Sono desideroso di ridurre al minimo i costi di trasferimento dei dati. Comprendo che il trasferimento dei dati tra un sito Web e uno spazio di archiviazione BLOB/tabella non comporta addebiti per il trasferimento dei dati (poiché non è considerato "in uscita") mentre i dati richiesti all'esterno del sito Web di Azure non lo fanno. In risposta a questo, ho 2 strategie per esporre le immagini al browser:

1.) Tramite l'URI al blob dell'immagine in memoria blu ad es. con account di archiviazione locale http://ipv4.fiddler:10000/devstoreaccount1/bcb2ad7581.jpg

2.) tramite web api che scarica i byte di immagine dalla memoria e li restituisce. per esempio. con host locale http://localhost:58559/api/image/bcb2ad7581.jpg

Queste sono le mie ipotesi. L'accesso diretto allo storage (metodo 1 sopra) è più efficiente. L'accesso alle immagini tramite web api (metodo 2 sopra) deve comportare spese generali che l'accesso diretto non ha, giusto? Ogni richiesta di API Web deve utilizzare un thread asp .net più cicli cpu. Per ogni richiesta di immagine API web elaborata, vale a dire una richiesta in meno per altre risorse API Web sul sito che non possono e devono essere accodate. D'altra parte qualsiasi sito esterno con cui l'immagine è condivisa aggiungerebbe un costo di trasferimento dati (tra gli altri costi) per ogni richiesta di immagine; se si accede tramite il metodo 1.

Quindi la mia strategia è quella di accedere alle immagini all'interno del sito tramite un collegamento diretto all'archiviazione (metodo 1) ad es. quando l'utente apre un album tutti i tag hanno azure blob azzurro nel loro attributo src. Tuttavia, quando l'utente fa clic sull'icona di Facebook per condividere, fornirò un collegamento all'immagine tramite web api (metodo 2). Mi rendo conto che l'utente può ignorare tutto ciò con plugin come il pulsante "PinIt", ecc., Ma va bene.

Sto solo imparando questa roba, quindi potrei essere lontano. Mi sbaglio se i costi di trasferimento in uscita non vengono applicati ai siti Web blu? Non penso di esserlo, ma l'intero modello di pricing è confuso, per non dire altro.

È l'accesso alla memoria BLOB da una pagina html del browser con tag e src atribute, considerato il trasferimento dei dati in uscita; anche se la pagina html proviene da un dominio di un sito Web azzurro? Voglio dire è solo gratuito quando il codice lato server accede allo storage, non al client html?

I costi di trasferimento dati salvati tramite il metodo 2 (se ce n'è uno) sono semplicemente annullati da un costo diverso associato al metodo web API (come il costo della larghezza di banda)?

Mi sbaglio riguardo al vantaggio in termini di prestazioni dell'accesso diretto all'archiviazione BLOB o forse a un errore relativo al sovraccarico delle richieste API Web?

Sono i primi tempi del progetto, quindi posso scaricare Azure se necessario. Preferirei non pensarci, perché penso che sia quello che sto cercando. Non voglio qualcosa per niente e sono felice di pagare per i servizi che consumo. Naturalmente, però, non voglio che la mia ignoranza mi costi.

Potrei fare con i vostri consigli, su questo, e veramente apprezzare il vostro aiuto.

Answer 1

per rispondere alle vostre domande:

mi sbaglio circa il trasferimento in uscita spese non viene applicata all'azzurro siti web?

Purtroppo, sì :) Tutti i dati che escono da un centro dati di Azure (DC) sono soggetti a costi di trasferimento in uscita e includono i dati forniti tramite i siti Web.

accede archiviazione blob da una pagina del browser HTML con la modifica e src atribute, considerato in uscita il trasferimento dei dati; anche se la pagina html proviene da un dominio sito Web azzurro? Voglio dire è gratuito solo quando il codice lato server accede alla memoria, non al client html?

Sì. Ricordare che il browser sta consumando i dati che si trovano all'esterno di Azure DC.

è del costo di trasferimento dei dati salvati tramite il metodo 2 (se davvero esiste), semplicemente annullati da un costo diverso associato al metodo API Web (come il costo della larghezza di banda)?

No. Poiché i dati alla fine escono da Azure DC (non importa se è tramite memoria direttamente o tramite web API).

mi sbaglio circa il beneficio delle prestazioni di accesso diretto alla memoria blob , o forse sbagliato il sovraccarico di richieste API Web?

Sicuramente otterrete maggiori vantaggi in termini di prestazioni fornendo un accesso diretto allo storage blob rispetto al trasferimento di dati tramite web api. Inoltre aumenterai anche la latenza.

Soluzione Raccomandazione

Per la vostra applicazione, posso raccomandare che si guarda Shared Access Signature funzionalità offerte da Azure Blob archiviazione. Credo che ciò migliorerà in modo significativo le prestazioni della tua applicazione.

Per i caricamenti, è possibile creare un URL SAS per caricare l'autorizzazione e fare in modo che l'applicazione Web carichi direttamente i file nella memoria BLOB. In questo modo i dati di upload non verranno instradati attraverso i tuoi server. Ho scritto alcuni post del blog sulla stessa, che si possono trovare utili:

http://gauravmantri.com/2013/02/16/uploading-large-files-in-windows-azure-blob-storage-using-shared-access-signature-html-and-javascript/

http://gauravmantri.com/2013/12/01/windows-azure-storage-and-cors-lets-have-some-fun/

Per scaricare le immagini, ancora una volta ho il Web API restituire un URL SAS invece di leggere i dati dell'immagine da stoccaggio blob e quindi inviare nuovamente i dati al browser client.