Prestazioni lente su Azure DocumentDB

Question

Attualmente sto affrontando tempi di risposta piuttosto lenti da Azure DocumentDB (la prima volta che lo provo).

Ci sono 31 oggetti in una collezione, che ho intenzione di recuperare e tornare al chiamante. Il codice che sto usando è questo:

public async Task<List<dynamic>> Get(string collectionName = null) 
{ 
    // Lookup from Dictionary, takes literally no time 
    var collection = await GetCollectionAsync(collectionName); 

    var sw = Stopwatch.StartNew(); 

    var query = await 
     _client.CreateDocumentQuery(collection.DocumentsLink, 
      new FeedOptions { MaxItemCount = 1000 }) 
      .AsDocumentQuery() 
      .ExecuteNextAsync(); 

    Trace.WriteLine($"Get documents: {sw.ElapsedMilliseconds} ms"); 

    return query.ToList(); 
} 

Per istanziare il cliente, sto utilizzando il seguente codice:

_client = new DocumentClient(new Uri(endpoint), authKey, new ConnectionPolicy 
{ 
    ConnectionMode = ConnectionMode.Direct, 
    ConnectionProtocol = Protocol.Tcp 
}); 

I tempi di risposta che sto ottenendo dalla Stopwatch è compreso tra 360ms e 1200ms a restituire 31 oggetti. Per me, questo è piuttosto lento. Senza l'ordinazione ConnectionPolicy il tempo di risposta medio è di circa 950 ms.

Sto facendo qualcosa di sbagliato qui? È possibile accelerare queste richieste in qualche modo?

Ecco l'output del Trace, stampando il tempo del cronometro trascorso:

Get documents: 1984 ms 
Get documents: 1252 ms 
Get documents: 1246 ms 
Get documents: 359 ms 
Get documents: 356 ms 
Get documents: 356 ms 
Get documents: 351 ms 
Get documents: 1248 ms 
Get documents: 1314 ms 
Get documents: 1250 ms 

Answer 1

aggiornato per riflettere le ultime modifiche al servizio (2017/01/22): DocumentDB garanzie p99 lettura di latenza < 10 ms e p99 latenza di scrittura < 15 ms con SLA sul lato del database. I suggerimenti di seguito si applicano ancora per ottenere una bassa latenza legge utilizzando gli SDK **

Aggiornato per riflettere ultime modifiche di servizio (6/14/2016): Non c'è alcuna necessità di memorizzare nella cache auto-link quando si utilizza l'instradamento via dall'utente ID definiti. Aggiunti anche alcuni altri suggerimenti. **

Le letture in genere richiedono < 1 ms sulla partizione di archiviazione di DocumentDB stessa; e il collo di bottiglia è spesso la latenza di rete tra l'applicazione e il database. Pertanto, è meglio avere l'applicazione in esecuzione nello stesso datacenter del database.

Ecco alcuni suggerimenti generali sull'utilizzo SDK:

Tip # 1: utilizzare un Singleton cliente DocumentDB per tutta la durata della vostra applicazione

Nota che ogni istanza DocumentClient è thread-safe ed esegue efficiente gestione delle connessioni e memorizzazione nella cache degli indirizzi durante il funzionamento in modalità diretta. Per consentire una gestione efficiente delle connessioni e prestazioni migliori di DocumentClient, si consiglia di utilizzare una singola istanza di DocumentClient per AppDomain per la durata dell'applicazione.

Tip # 2: Scheda Cache e SelfLinks di raccolta per i più bassa latenza leggono

In Azure DocumentDB, questo documento ha un selfLink generato dal sistema. Questi collegamenti automatici sono garantiti come unici e immutabili per la durata del documento. Leggere un singolo documento usando un collegamento automatico è il modo più efficiente per ottenere un singolo documento. A causa dell'immutabilità di SelfLink, è opportuno memorizzare nella cache i collegamenti automatici laddove possibile per ottenere prestazioni di lettura ottimali.

Detto questo, potrebbe non essere sempre possibile per l'applicazione utilizzare l'autolink di un documento per gli scenari di lettura; in questo caso, il prossimo modo più efficiente per recuperare un documento è eseguire una query in base alla proprietà Id fornita dall'utente del documento. Per esempio:

IDocumentQuery<Document> query = (from doc in client.CreateDocumentQuery(colSelfLink) where doc.Id == "myId" select document).AsDocumentQuery(); 
      Document myDocument = null; 
      while (query.HasMoreResults) 
      { 
       FeedResponse<Document> res = await query.ExecuteNextAsync<Document>(); 
       if (res.Count != 0) { 
        myDocument = res.Single(); 
        break; 
       } 
      } 

Tip # 3: Tune dimensione della pagina per le query/leggere i feed per migliorare le prestazioni

quando si esegue una lettura di massa di documenti che utilizzano la funzionalità di alimentazione leggere (cioè ReadDocumentFeedAsync) o quando si esegue una query SQL DocumentDB, i risultati vengono restituiti in modo segmentato se il set di risultati è troppo grande. Per impostazione predefinita, i risultati vengono restituiti in blocchi di 100 elementi o 1 MB, a seconda di quale limite viene raggiunto per primo.

Per ridurre il numero di round trip della rete necessari per recuperare tutti i risultati applicabili, è possibile aumentare le dimensioni della pagina utilizzando l'intestazione della richiesta x-ms-max-item-count fino a 1000. Nei casi in cui è necessario visualizzare solo alcuni risultati, ad esempio, se l'interfaccia utente o l'API dell'applicazione restituisce solo dieci risultati alla volta, è inoltre possibile ridurre la dimensione della pagina a 10 per ridurre il throughput utilizzato per le letture e le query.

È inoltre possibile impostare le dimensioni della pagina utilizzando gli SDK DocumentDB disponibili. Per esempio:

IQueryable<dynamic> authorResults = 
client.CreateDocumentQuery(documentCollection.SelfLink, "SELECT p.Author FROM Pages p WHERE p.Title = 'About Seattle'", new FeedOptions { MaxItemCount = 1000 }); 

Alcuni ulteriori suggerimenti (6/14/2016):

• Usa punto-legge (ad esempio, leggere il documento, invece di documento query) per la ricerca per ID
• Configurare il client DocumentDB (utilizzando ConnectionPolicy) per utilizzare la connettività diretta sul gateway
• Collocare i client nella stessa area di Azure del database
• Chiamare op enAsync() per evitare alti prima latenza chiamata
• È possibile eseguire il debug di query LINQ chiamando ToString() sul interrogabile per vedere la query SQL inviati attraverso il filo

Per ulteriori suggerimenti di prestazioni, controlla questo blog post.