Ho un numero piuttosto elevato (30 mln righe, fino a 5-100 KB ciascuna) Tabella su Azure.
Ogni RowKey
è un GUID e PartitionKey
è una prima parte Guid, ad esempio:Come ridurre la latenza di Archiviazione tabella di Azure?
PartitionKey = "1bbe3d4b"
RowKey = "1bbe3d4b-2230-4b4f-8f5f-fe5fe1d4d006"
tabella include 600 letture e 600 scritture (aggiornamenti) al secondo con una latenza media di 60ms. Tutte le query utilizzano sia PartitionKey
e RowKey
.
MA alcune letture richiedono fino a 3000 ms (!). In media, l'1% di tutte le letture richiede più di 500ms e non vi è alcuna correlazione con la dimensione dell'entità (la riga 100Kb può essere restituita in 25ms e 10Kb una - in 1500ms).
La mia applicazione è un sito Web ASP.Net MVC 4 in esecuzione su 4-5 istanze di grandi dimensioni.
Ho letto tutti gli articoli di MSDN per quanto riguarda gli obiettivi di performance Azure Table di stoccaggio e già ha fatto la seguente:
UseNagle
è spentoExpect100Continue
è anche disattivatoMaxConnections
per il cliente tabella è impostato su 250 (impostazione 1000-5000 non ha senso)
Inoltre ho controllato che:
- contatori di monitoraggio account di archiviazione non presentino errori di limitazione
- Ci sono una sorta di "onde" in termini di prestazioni, anche se non dipende dal carico
Quale potrebbe essere il motivo di tali problemi di prestazioni e come migliorarlo?
Il tuo account di archiviazione trova nella stessa regione di tuo sito web? –
Per una determinata PartitionKey, approssimativamente quante righe hai? Per le 600 letture e 600 scritture, si verificano all'interno della stessa PartitionKey o sono distribuite su più partizioni? –
@ zain-rizvi, sì, di causa, tra regioni non sarei in grado di ottenere 60ms in media. –