Limitazioni delle transazioni di Archiviazione tabella di Azure

Question

Sto eseguendo test delle prestazioni contro ATS e si comporta in modo un po 'strano quando si utilizzano più macchine virtuali contro lo stesso account tabella/memoria.

L'intera pipeline non è bloccante (attesa/asincrona) e utilizza TPL per l'esecuzione simultanea e parallela.

Prima di tutto è molto strano che con questa configurazione sto ottenendo solo circa 1200 inserimenti. Funziona su un box L VM, cioè 4 core + 800mbps.

Inserisco 100.000 righe con PK univoco e RK univoco, che dovrebbero sfruttare la distribuzione definitiva.

Un comportamento ancora più deterministico è il seguente.

Quando eseguo 1 VM, ottengo circa 1200 inserimenti al secondo. Quando eseguo 3 VM ottengo circa 730 su ogni inserimento al secondo.

È piuttosto umoristico leggere il post sul blog in cui stanno specificando i propri obiettivi. https://azure.microsoft.com/en-gb/blog/windows-azures-flat-network-storage-and-2012-scalability-targets/

singola tabella Partition- una partizione tavolo sono tutte le entità in una tabella con lo stesso valore di chiave di partizione, e di solito le tabelle hanno molte partizioni. L'obiettivo di throughput per una singola partizione tabella è:

Fino a 2.000 soggetti al secondo

Nota, questo è per una singola partizione, e non una sola tabella. Pertanto, una tabella con un buon partizionamento può elaborare fino a 20.000 entità/secondo, che è l'obiettivo generale dell'account sopra descritto.

Cosa devo fare per essere in grado di utilizzare il 20k al secondo e come sarebbe possibile eseguire più di 1,2k per VM?

-

Aggiornamento:

Ora ho provato anche con 3 account di archiviazione per ogni singolo nodo e sta ancora ricevendo il comportamento prestazioni/limitazione. Quale non riesco a trovare una ragione logica per.

-

Aggiornamento 2:

Ho ottimizzato il codice ulteriormente e ora sto possibile eseguire circa 1550

-

Update 3:

Ora ho provato anche negli Stati Uniti occidentali. La performance è peggio lì. Circa il 33% in meno.

-

Update 4:

ho provato l'esecuzione del codice da una macchina XL. Che è 8 core invece di 4 e la doppia quantità di memoria e larghezza di banda e ha ottenuto un aumento del 2% delle prestazioni, quindi chiaramente questo problema non è dalla mia parte ..

Answer 1

Le istanze di calcolo e l'account di archiviazione si trovano nello stesso gruppo di affinità? I gruppi di affinità assicurano che la prossimità di rete tra i servizi sia ottimale e dovrebbe comportare una minore latenza a livello di rete.

È possibile trovare la configurazione del gruppo di affinità nella scheda di rete.

Answer 2

Sospetto che questo possa avere a che fare con TCP Nagle. Vedere this MSDN article e this blog post.

In pratica, TCP Nagle è un'ottimizzazione a livello di protocollo che raggruppa piccole richieste. Poiché stai inviando molte piccole richieste, è probabile che ciò influenzi negativamente il rendimento.

È possibile disattivare il protocollo TCP Nagle eseguendo questo codice quando si avvia l'applicazione

ServicePointManager.UseNagleAlgorithm = false; 

Answer 3

tenderei a credere che il throughput massimo è per un carico ottimizzato. Ad esempio, scommetto che è possibile ottenere prestazioni più elevate utilizzando le richieste Batch rispetto alle singole richieste che si stanno facendo ora. E, naturalmente, se utilizzi GUID per il tuo PK, non puoi eseguire il batch nel tuo test corrente.

Quindi, cosa succede se si è modificato il test in entità di inserimento batch in gruppi di 100 (massimo per batch), utilizzando ancora GUID, ma per i quali 100 entità avrebbero lo stesso PK?

Answer 4

Alcuni commenti:

1. Lei ha accennato che si sta utilizzando PK unico/RK per ottenere ultima distribuzione, ma è necessario tenere a mente che il bilanciamento PK è non è immediato. Quando crei per la prima volta una tabella, l'intera tabella sarà servita da 1 server di partizione. Pertanto, se si eseguono inserimenti su diversi PKs , essi andranno comunque a un server di partizione e verranno colti dalla priorità di scalabilità per una singola partizione . Il master di partizione inizierà a suddividere le tue partizioni tra più server di partizione dopo che ha identificato i server di partizione hot . Nel tuo test di 2 minuti < non vedrai il vantaggio di più server Partiton o PK. Il throughput dell'articolo è mirato a uno schema PK ben distribuito con i dati di accesso frequente , causando la suddivisione dei dati tra i server di partizione multipli di .

2. La dimensione della VM non è il problema come non sono bloccati su CPU, memoria o larghezza di banda. È possibile ottenere prestazioni di storage complete da una piccola dimensione VM.

3. Partenza http://research.microsoft.com/en-us/downloads/5c8189b9-53aa-4d6a-a086-013d927e15a7/default.aspx. Ho appena eseguito un test rapido utilizzando lo strumento da una VM WebRole nello stesso datacenter dello come account di archiviazione e da una singola istanza dello strumento su una singola VM, ~ 2800 elementi al secondo di caricamento e ~ Download di 7300 elementi al secondo. Questo utilizza 1024 byte entità, 10 thread e 100 dimensioni batch. Non so quanto sia efficiente questo strumento o disattiva Nagles Algorithm perché non sono riuscito a ottenere ottimi risultati (ho ottenuto ~ 1000/secondo) utilizzando una dimensione batch di 1, ma almeno con la dimensione di 100 lotti mostra che puoi ottenere oggetti alti/secondi. Questo è stato fatto nell'US West.

4. Si sta utilizzando la libreria client di archiviazione 1.7 (Microsoft.Azure.StorageClient.dll) o 2.0 (Microsoft.Azure.Storage.dll)? La libreria 2.0 presenta alcuni miglioramenti delle prestazioni e dovrebbe produrre risultati migliori.