Numero di istanze necessarie per l'applicazione Windows Azure

Question

Sono relativamente nuovo a Windows Azure e desidero ospitare un'applicazione di sondaggio che verrà compilata da appr. 30.000 utenti simultaneamente.

L'applicazione consiste di 1 pagina .aspx che verrà inviata al client una volta, fa 25 domande e darà un riepilogo delle risposte fornite alla fine. Quando l'utente ha dato la risposta e fa clic sui pulsanti "domanda successiva", la risposta data verrà inviata tramite un gestore .ashx al server. La risposta è la prossima domanda e risposta. Il wrap-up viene inviato al client dopo un postback completo. La risposta viene salvata in una tabella di Azure partizionata in modo che ciascuna partizione possa contenere un massimo di 450 utenti.

Vorrei chiedere se qualcuno può dare un'ipotesi stimata su quante istanze di ruolo Web dobbiamo avviare per far sì che questa applicazione continui a funzionare. (Se è troppo difficile da dire, è più probabile iniziare 5, 50 o 500 istanze?)

Qual è un modo migliore per andare: 20 piccole istanze o 5 grandi istanze?

Grazie per il vostro aiuto!

Answer 1

La risposta più ovvia: si sarebbe meglio servire testando questo te stesso e vedere come la vostra applicazione regge. È possibile ottenere facilmente contatori delle prestazioni e altri programmi di diagnostica da Windows Azure; ad esempio, è possibile connettere Microsoft SCOM (System Center Operations Manager) per monitorare l'ambiente durante il test. Site Hammer è un semplice strumento di test del carico per Windows Azure (su MSDN code gallery).

A prescindere da questa risposta molto ovvia, condividerò alcune ipotesi: dato il tipo di carico, probabilmente è meglio con istanze più piccole rispetto a un numero inferiore di quelle grandi, soprattutto perché hai già il tuo spazio partizionato . Se hai davvero 30K di visitatori simultaneamente e dai loro un intervallo di ~ 15 secondi tra la lettura delle domande & postando le loro risposte stai guardando 2.000 richieste al secondo. 10 nodi dovrebbero essere più che sufficienti per gestire quel carico. Ricorda che questa è solo una semplice stima, priva di qualsiasi forma di intuizione nella tua architettura, ecc. Per questi tipi di carichi, il caching è un'ottima idea; aumenterà notevolmente il carico che ogni nodo può gestire.

Tuttavia, il miglior consiglio che posso darti è quello di assicurarti di monitorare attivamente. Sono necessari meno di 30 minuti per creare istanze aggiuntive, quindi se controlli il tuo ambiente e/o assicurati di essere avvisato ogni volta che inizia a soffocare, puoi facilmente aggiornare la tua configurazione. Tieni presente che devi contattare l'assistenza clienti per poter superare più di 20 istanze (questo è un limite predefinito, in atto per proteggerti dall'eccessiva spesa).

Answer 2

A parte il saggio consiglio che tijmenvdk ti ha dato, permettimi di aggiungere la mia opinione sulla dimensione dell'istanza. In generale, vai con la dimensione più piccola che supporterà la tua app, quindi ridimensiona per gestire il traffico aumentato. In questo modo, quando si ridimensiona, il costo minimo di elaborazione viene mantenuto basso. Se hai eseguito, ad esempio, un paio di istanze extra-large come linea di base (poiché desideri sempre almeno due istanze per ottenere lo SLA uptime), l'ingombro dei costi inizia a 0,12 x 8 x 2 = $ 1,92 all'ora, anche durante i bassi tempi di traffico. Se vai con istanze piccole, saresti a 0,12 x 1 x 2 = $ 0,24 all'ora.

Ogni dimensione VM come CPU associata, la memoria, e) storage locale su disco 9non-resistente, in modo da scegliere l'unità di misura più piccola che la vostra applicazione funziona in modo efficiente in.

Per il carico/prestazioni-test, si potrebbe anche voler considerare una soluzione ospitata come Loadstorm.

Answer 3

Quanto sono simultanee le richieste in realtà? Verranno digitati tutti esattamente nello stesso momento?

Detto questo, profilo localmente la tua app, questo ti permetterà di stimare l'utilizzo della CPU, della rete e della memoria su Azure. Quindi, piuttosto che guardare quante istanze hai bisogno, guarda come puoi ridurre il requisito! Applicare nuovamente questi suggerimenti e il profilo in locale.

La maggior parte dei suggerimenti per le prestazioni ha un compromesso tra l'utilizzo della cpu, della memoria o della larghezza di banda, l'idea è di garantire che abbiano una scala uguale. Se la tua applicazione ha esaurito la memoria, ma hai un sacco di CPU e rete, non Per un sondaggio a pagina singola, assicurati che il tuo html, css & js sia minimizzato, assicurati che sia memorizzato nella cache.

Combinarli se possibile e per ottenere una scalabilità davvero efficace, è possibile trasferire file statici (css, js & immagini) in un CDN. Tutto ciò riduce il numero di richieste che il server web deve affrontare e quindi riduce il numero di webroles di cui avrai bisogno = meno rete.

Come restituisce la risposta l'ashx? cioè sta inviando html, xml o json? personalmente, vorrei che restituisse JSON, in quanto ciò richiederà meno larghezza di banda di rete e molto probabilmente meno elaborazione lato server = meno memoria e rete.

Uso asincrono API per accedere stoccaggio azure (puo utilizza porte di completamento IO per liberare il filo IIS per gestire più richieste fino stoccaggio azzurro torna = consentendo CPU in scala)

tijmenvdk ha già menzionato utilizzando code per scrivere . L'elenco delle domande cambia? in caso contrario, memorizzali nella cache, in modo che l'app debba solo leggere dalla memoria della tabella una volta all'avvio e una volta per ogni client per il wrap-up finale = salva la rete e la cpu a spese della memoria.

Tutti questi suggerimenti sono ugualmente applicabili a una normale applicazione Web, su un singolo server o ambiente Web-farm.

Il punto che sto cercando di fare è che ciò che non si può misurare, non si può migliorare, e la misurazione, il miglioramento e il costo vanno tutti di pari passo. Il ridimensionamento dinamico ridurrà i costi, ma fondamentalmente se la vostra applicazione non è stata misurata e l'utilizzo delle risorse ottimizzato, chiedendo quante istanze avete bisogno è inutile.