Suggerimenti sulle prestazioni per Azure Cosmos DB Java SDK v4
SI APPLICA A: 
NoSQL
Importante
I suggerimenti sulle prestazioni riportati in questo articolo riguardano esclusivamente Azure Cosmos DB Java SDK v4. Per altre informazioni, vedere le note sulla versione di Azure Cosmos DB Java SDK v4, il repository Maven e la guida alla risoluzione dei problemi di Azure Cosmos DB Java SDK v4. Se attualmente si usa una versione precedente a v4, vedere l'articolo Eseguire la migrazione a Java SDK v4 per Azure Cosmos DB per informazioni sull'aggiornamento a v4.
Azure Cosmos DB è un database distribuito veloce e flessibile, facilmente scalabile e con latenza e velocità effettiva garantite. Non è necessario apportare modifiche significative all'architettura o scrivere codice complesso per ridimensionare il database con Azure Cosmos DB. Aumentare o ridurre le prestazioni è semplice come eseguire una singola chiamata API o una chiamata al metodo SDK. Tuttavia, dato che si accede ad Azure Cosmos DB tramite chiamate di rete, è possibile introdurre ottimizzazioni sul lato client per ottenere massime prestazioni durante l'uso di Azure Cosmos DB Java SDK v4.
Se si vogliono migliorare le prestazioni del database, valutare le opzioni seguenti:
Rete
Quando possibile, posizionare eventuali applicazioni che chiamano Azure Cosmos DB nella stessa area del database Azure Cosmos DB. Per un confronto approssimativo, le chiamate ad Azure Cosmos DB eseguite nella stessa area vengono completate entro 1-2 millisecondi, mentre la latenza tra la costa occidentale e quella orientale degli Stati Uniti è >50 millisecondi. Questa latenza può variare da richiesta a richiesta, in base alla route seguita dalla richiesta durante il passaggio dal client al limite del data center di Azure. È possibile ottenere la latenza più bassa possibile assicurandosi che l'applicazione chiamante si trovi nella stessa area di Azure in cui si trova l'endpoint di Azure Cosmos DB con provisioning. Per un elenco delle aree disponibili, vedere Aree di Azure.
Un'app che interagisce con un account Azure Cosmos DB per più aree deve configurare località preferite per garantire che le richieste vengano inviate a un'area collocata.
Abilitare la rete accelerata per ridurre la latenza e l'instabilità della CPU
È consigliabile seguire le istruzioni per abilitare la rete accelerata in Windows (selezionare per istruzioni) o Linux (selezionare per istruzioni) macchina virtuale di Azure per ottimizzare le prestazioni riducendo la latenza e il jitter della CPU.
Senza rete accelerata, l'I/O che transita tra la macchina virtuale di Azure e altre risorse di Azure potrebbe essere instradata tramite un host e un commutatore virtuale situato tra la macchina virtuale e la relativa scheda di rete. La presenza dell'host e del commutatore virtuale inline nel percorso dei dati non solo aumenta la latenza e l'instabilità nel canale di comunicazione, ma sottrae anche cicli della CPU alla macchina virtuale. Con la rete accelerata, le interfacce vm direttamente con la scheda di interfaccia di rete senza intermediari. Tutti i dettagli dei criteri di rete vengono gestiti nell'hardware nella scheda di interfaccia di rete, ignorando l'host e il commutatore virtuale. Quando si abilita la rete accelerata, è in genere possibile prevedere una latenza più bassa e una velocità effettiva più elevata, oltre a una maggiore latenza coerente e a un minore utilizzo della CPU.
Limitazioni: la rete accelerata deve essere supportata nel sistema operativo della macchina virtuale e può essere abilitata solo quando la macchina virtuale viene arrestata e deallocata. La macchina virtuale non può essere distribuita con Azure Resource Manager. Servizio app non ha alcuna rete accelerata abilitata.
Per altre informazioni, vedere le istruzioni di Windows e Linux .
Ottimizzazione della configurazione della connessione diretta e gateway
Per ottimizzare le configurazioni di connessione in modalità diretta e gateway, vedere come ottimizzare le configurazioni di connessione per Java SDK v4.
Uso dell'SDK
- Installare l'SDK più recente
Agli SDK di Azure Cosmos DB vengono apportati continui miglioramenti per offrire prestazioni ottimali. Per determinare i miglioramenti più recenti dell'SDK , visitare Azure Cosmos DB SDK.
Ogni istanza del client Azure Cosmos DB è thread-safe ed esegue la gestione efficiente delle connessioni e la memorizzazione nella cache degli indirizzi. Per consentire una gestione efficiente delle connessioni e prestazioni migliori dal client Azure Cosmos DB, è consigliabile usare una singola istanza del client Azure Cosmos DB per la durata dell'applicazione.
Quando si crea un CosmosClient, la coerenza predefinita usata, se non impostata in modo esplicito, è Session. Se la coerenza Session non è richiesta dalla logica dell'applicazione, impostare Consistency su Eventual. Nota: è consigliabile usare almeno la coerenza della sessione nelle applicazioni che usano il processore del feed di modifiche di Azure Cosmos DB.
- Usare l'API Async per la massima velocità effettiva di cui viene effettuato il provisioning
Azure Cosmos DB Java SDK v4 include due API, Sync e Async. In linea generale, l'API Async implementa la funzionalità dell'SDK, mentre l'API Sync è un thin wrapper che blocca le chiamate all'API Async. Questo è in contrasto con il precedente Azure Cosmos DB Async Java SDK v2, che era solo asincrono, e con il precedente Azure Cosmos DB Sync Java SDK v2, che era solo sincronizzazione e aveva un'implementazione separata.
La scelta dell'API viene determinata durante l'inizializzazione del client. CosmosAsyncClient supporta l'API Async, mentre CosmosClient supporta l'API Sync.
L'API asincrona implementa operazioni di I/O non bloccanti ed è la scelta ottimale se l'obiettivo è quello di aumentare la velocità effettiva quando si emettono richieste ad Azure Cosmos DB.
L'uso dell'API di sincronizzazione può essere la scelta giusta se si vuole o è necessaria un'API, che si blocca sulla risposta a ogni richiesta o se l'operazione sincrona è il paradigma dominante nell'applicazione. Può ad esempio essere opportuno usare l'API Sync quando si salvano in modo permanente i dati di Azure Cosmos DB in un'applicazione di microservizi, purché la velocità effettiva non sia fondamentale.
Si noti che la velocità effettiva dell'API di sincronizzazione peggiora con un aumento del tempo di risposta delle richieste, mentre l'API asincrona può saturare le funzionalità complete della larghezza di banda dell'hardware.
La collocazione geografica può offrire una velocità effettiva più elevata e coerente quando si usa l'API Sync (vedere Collocare i client nella stessa area di Azure per ottenere migliori prestazioni), ma non si prevede ancora di superare la velocità effettiva ottenibile dall'API Async.
Alcuni utenti potrebbero anche non avere familiarità con Project Reactor, il framework dei flussi reattivi usato per implementare l'API Async di Azure Cosmos DB Java SDK v4. Se questo rappresenta un problema, è consigliabile leggere la guida introduttiva ai modelli di Reactor e quindi esaminare l'introduzione alla programmazione reattiva per acquisire familiarità con questi concetti. Se si è già usato Azure Cosmos DB con un'interfaccia asincrona e l'SDK usato era Azure Cosmos DB Async Java SDK v2, è possibile che si abbia già familiarità con ReactiveX/RxJava ma non si sappia esattamente cosa è cambiato in Project Reactor. In tal caso, esaminare la Guida ai reattori e RxJava per acquisire familiarità.
I frammenti di codice seguenti mostrano come inizializzare il client di Azure Cosmos DB rispettivamente per il funzionamento dell'API Async o dell'API Sync:
API asincrona Java SDK V4 (Maven com.azure::azure-cosmos)
CosmosAsyncClient client = new CosmosClientBuilder()
.endpoint(HOSTNAME)
.key(MASTERKEY)
.consistencyLevel(CONSISTENCY)
.buildAsyncClient();
- Aumentare il carico di lavoro client
Se si sta eseguendo il test a livelli di velocità effettiva elevati, l'applicazione client può diventare un collo di bottiglia a causa della limitazione di uso della CPU o della rete. In questo caso, è possibile continuare a effettuare il push dell'account Azure Cosmos DB aumentando il numero di istanze delle applicazioni client in più server.
Una regola empirica efficace è quella di non superare del >50% l'utilizzo della CPU su un determinato server, per mantenere bassa la latenza.
- Usare l'utilità di pianificazione appropriata (evitare l'acquisizione di thread Netty di I/O EventLoop)
La funzionalità asincrona di Azure Cosmos DB Java SDK si basa sull'I/O non bloccante Netty. L'SDK usa un numero fisso di thread Netty di I/O EventLoop (corrispondente al numero di core della CPU del computer) per l'esecuzione di operazioni di I/O. La sequenza Flux restituita dall'API genera il risultato in uno dei thread Netty di I/O EventLoop condiviso. Per questo motivo è importante non bloccare i thread Netty di I/O EventLoop condivisi. L'esecuzione di operazioni con utilizzo intensivo della CPU oppure di operazioni di blocco sul thread Netty di I/O EventLoop può causare deadlock o ridurre in modo significativo la velocità effettiva dell'SDK.
Ad esempio il codice seguente esegue un'operazione con utilizzo intensivo della CPU sul thread Netty di I/O EventLoop:
Mono<CosmosItemResponse<CustomPOJO>> createItemPub = asyncContainer.createItem(item);
createItemPub.subscribe(
itemResponse -> {
//this is executed on eventloop IO netty thread.
//the eventloop thread is shared and is meant to return back quickly.
//
// DON'T do this on eventloop IO netty thread.
veryCpuIntensiveWork();
});
Dopo aver ricevuto il risultato, è consigliabile evitare di eseguire operazioni con utilizzo intensivo della CPU sul risultato nel thread netty di I/O del ciclo di eventi. In alternativa, è possibile specificare la propria utilità di pianificazione per fornire il proprio thread per l'esecuzione del lavoro, come mostrato di seguito (import reactor.core.scheduler.Schedulers necessario).
Mono<CosmosItemResponse<CustomPOJO>> createItemPub = asyncContainer.createItem(item);
createItemPub
.publishOn(Schedulers.parallel())
.subscribe(
itemResponse -> {
//this is now executed on reactor scheduler's parallel thread.
//reactor scheduler's parallel thread is meant for CPU intensive work.
veryCpuIntensiveWork();
});
In base al tipo di lavoro, è consigliabile utilizzare l'Utilità di pianificazione reattore esistente appropriata per il lavoro. Per altre informazioni, vedere qui Schedulers.
Per altre informazioni sul modello di threading e pianificazione del progetto Reactor, fare riferimento a questo post di blog di Project Reactor.
Per altre informazioni su Azure Cosmos DB Java SDK v4, vedere la directory azure Cosmos DB di Azure SDK per Java monorepo in GitHub.
- Ottimizzare le impostazioni di registrazione nell'applicazione
Per vari motivi, è necessario aggiungere la registrazione in un thread che genera una velocità effettiva elevata delle richieste. Se l'obiettivo è quello di saturare completamente, con le richieste generate da questo thread, la velocità effettiva di un contenitore di cui viene effettuato il provisioning, le ottimizzazioni della registrazione possono migliorare significativamente le prestazioni.
- Configurare un logger asincrono
La latenza di un logger sincrono implica necessariamente il calcolo della latenza complessiva del thread che genera richieste. È consigliabile un logger asincrono, ad esempio log4j2, per separare l'overhead di registrazione dai thread dell'applicazione a prestazioni elevate.
- Disabilitare la registrazione di Netty
La registrazione della libreria Netty è molto dettagliata e deve essere disattivata (la soppressione dell'accesso alla configurazione potrebbe non essere sufficiente) per evitare costi aggiuntivi di CPU. Se non si è in modalità di debug, disabilitare del tutto la registrazione di Netty. Pertanto, se si usa Log4j per evitare i costi della CPU aggiuntivi causati da org.apache.log4j.Category.callAppenders() da Netty aggiungere la riga seguente alla codebase:
org.apache.log4j.Logger.getLogger("io.netty").setLevel(org.apache.log4j.Level.OFF);
- Limite di risorse per i file aperti del sistema operativo
Alcuni sistemi Linux (ad esempio Red Hat) prevedono un limite massimo per il numero di file aperti e quindi per il numero totale di connessioni. Eseguire il comando seguente per visualizzare i limiti correnti:
ulimit -a
Il numero di file aperti (nofile) deve essere sufficientemente grande da disporre di spazio sufficiente per le dimensioni del pool di connessioni configurate e per altri file aperti dal sistema operativo. Può essere modificato per consentire dimensioni del pool di connessioni più grandi.
Aprire il file limits.conf:
vim /etc/security/limits.conf
Aggiungere/modificare le righe seguenti:
* - nofile 100000
- Specificare la chiave della partizione nelle scritture di punti
Per migliorare le prestazioni delle scritture di punti, specificare la chiave della partizione dell'elemento nella chiamata all'API per le scritture di punti, come mostrato di seguito:
API asincrona Java SDK V4 (Maven com.azure::azure-cosmos)
asyncContainer.createItem(item,new PartitionKey(pk),new CosmosItemRequestOptions()).block();
Anziché fornire solo l'istanza dell'elemento, come illustrato di seguito:
API asincrona Java SDK V4 (Maven com.azure::azure-cosmos)
asyncContainer.createItem(item).block();
Quest'ultima è supportata, ma aggiungerà latenza all'applicazione. L'SDK deve analizzare l'elemento ed estrarre la chiave della partizione.
Operazioni di query
Per le operazioni di query, vedere i suggerimenti sulle prestazioni per le query.
Criteri di indicizzazione
- Escludere i percorsi non usati dall'indicizzazione per scritture più veloci
I criteri di indicizzazione di Azure Cosmos DB consentono di specificare i percorsi dei documenti da includere o escludere dall'indicizzazione usando i percorsi di indicizzazione (setIncludedPaths e setExcludedPaths). L'uso dei percorsi di indicizzazione può consentire di ottenere prestazioni migliori e di ridurre le risorse di archiviazione dell'indice per gli scenari in cui i modelli di query sono noti in anticipo, poiché i costi dell'indicizzazione sono correlati direttamente al numero di percorsi univoci indicizzati. Il codice seguente, ad esempio, mostra come includere ed escludere dall'indicizzazione intere sezioni dei documenti (nota anche come sottoalbero) usando il carattere jolly "*".
CosmosContainerProperties containerProperties = new CosmosContainerProperties(containerName, "/lastName");
// Custom indexing policy
IndexingPolicy indexingPolicy = new IndexingPolicy();
indexingPolicy.setIndexingMode(IndexingMode.CONSISTENT);
// Included paths
List<IncludedPath> includedPaths = new ArrayList<>();
includedPaths.add(new IncludedPath("/*"));
indexingPolicy.setIncludedPaths(includedPaths);
// Excluded paths
List<ExcludedPath> excludedPaths = new ArrayList<>();
excludedPaths.add(new ExcludedPath("/name/*"));
indexingPolicy.setExcludedPaths(excludedPaths);
containerProperties.setIndexingPolicy(indexingPolicy);
ThroughputProperties throughputProperties = ThroughputProperties.createManualThroughput(400);
database.createContainerIfNotExists(containerProperties, throughputProperties);
CosmosAsyncContainer containerIfNotExists = database.getContainer(containerName);
Per altre informazioni, vedere l'articolo relativo ai criteri di indicizzazione di Azure Cosmos DB.
Velocità effettiva
- Misurare e ottimizzare per ottenere un utilizzo minore di unità richiesta al secondo
Azure Cosmos DB offre un'ampia gamma di operazioni di database, incluse le query relazionali e gerarchiche con funzioni definite dall'utente, stored procedure e trigger, operative nei documenti in una raccolta di database. Il costo associato a ognuna di queste operazioni dipende da CPU, I/O e memoria necessari per il completamento dell'operazione. Invece di occuparsi della pianificazione e della gestione delle risorse hardware, sarà possibile usare un'unità di richiesta come misura singola per le risorse necessarie per eseguire diverse operazioni di database e rispondere a una richiesta dell'applicazione.
Viene eseguito il provisioning della velocità effettiva in base al numero di unità richiesta impostato per ogni contenitore. Il consumo delle unità di richiesta è valutato in base alla frequenza al secondo. Le applicazioni che superano la frequenza di unità richiesta con provisioning previsto per il contenitore sono limitate fino al ritorno della frequenza sotto il valore riservato per il contenitore. Se l'applicazione necessita di un livello superiore di velocità effettiva, sarà possibile aumentare la velocità effettiva eseguendo il provisioning di unità di richiesta aggiuntive.
La complessità di una query influisce sulla quantità di unità richiesta usate per un'operazione. Il numero di predicati, la natura dei predicati, il numero di funzioni definite dall'utente e le dimensioni del set di dati di origine sono tutti fattori che incidono sul costo delle operazioni di query.
Per misurare l'overhead di qualsiasi operazione (create, update o delete), esaminare l'intestazione x-ms-request-charge per determinare il numero di unità richiesta usate da queste operazioni. È anche possibile esaminare la proprietà RequestCharge equivalente in ResourceResponse<T> o FeedResponse<T>.
API asincrona Java SDK V4 (Maven com.azure::azure-cosmos)
CosmosItemResponse<CustomPOJO> response = asyncContainer.createItem(item).block();
response.getRequestCharge();
L'addebito richiesta restituito in questa intestazione è una frazione della velocità effettiva con provisioning. Ad esempio, se è stato effettuato il provisioning di 2000 UR/sec e se la query precedente restituisce 1.000 documenti da 1 KB, il costo dell'operazione è 1000. Entro un secondo, il server rispetterà quindi solo due richieste di questo tipo prima di limitare la velocità delle richieste successive. Per altre informazioni, vedere Unità richiesta e il calcolatore di unità richiesta.
- Gestire la limitazione della frequenza o una frequenza di richieste troppo elevata
Quando un client prova a superare la velocità effettiva riservata per un account, non si verifica alcun calo delle prestazioni del server e l'uso della capacità della velocità effettiva non supera il livello riservato. Il server termina preventivamente la richiesta con RequestRateTooLarge (codice di stato HTTP 429) e restituisce l'intestazione x-ms-retry-after-ms, che indica la quantità di tempo, in millisecondi, che l'utente deve attendere prima di eseguire di nuovo la richiesta.
HTTP Status 429,
Status Line: RequestRateTooLarge
x-ms-retry-after-ms :100
Tutti gli SDK intercettano implicitamente questa risposta, rispettano l'intestazione retry-after specificata dal server e ripetono la richiesta. A meno che all'account non accedano contemporaneamente più client, il tentativo successivo riuscirà.
Se più client operano cumulativamente in modo costante al di sopra della frequenza delle richieste, il numero di ripetizioni dei tentativi predefinito attualmente impostato su 9 internamente dal client potrebbe non essere sufficiente. In questo caso, il client genererà un'eccezione CosmosClientException con codice di stato 429 per l'applicazione. Il numero di tentativi predefinito può essere modificato usando setMaxRetryAttemptsOnThrottledRequests() nell'istanza di ThrottlingRetryOptions . Per impostazione predefinita, l'eccezione CosmosClientException con codice di stato 429 viene restituita dopo un tempo di attesa cumulativo di 30 secondi, se la richiesta continua a funzionare al di sopra della frequenza delle richieste. Ciò si verifica anche quando il numero di ripetizioni dei tentativi corrente è inferiore al numero massimo di tentativi, indipendentemente dal fatto che si tratti del valore predefinito 9 o di un valore definito dall'utente.
Benché il comportamento automatizzato per la ripetizione dei tentativi consenta di migliorare la resilienza e l'usabilità per la maggior parte delle applicazioni, è possibile che provochi conflitti durante l'esecuzione dei benchmark delle prestazioni, in particolare durante la misurazione della latenza. La latenza osservata dal client presenterà dei picchi se l'esperimento raggiunge il limite del server e fa in modo che l'SDK client ripeta automaticamente i tentativi. Per evitare i picchi di latenza durante gli esperimenti relativi alle prestazioni, misurare l'addebito restituito da ogni operazione e assicurarsi che le richieste operino al di sotto della frequenza delle richieste riservata. Per altre informazioni, vedere Unità richiesta.
- Progettare documenti di dimensioni minori per ottenere una velocità effettiva maggiore
L'addebito per le richieste, ovvero il costo di elaborazione delle richieste, per un'operazione specifica è correlato direttamente alle dimensioni del documento. Le operazioni sui documenti di grandi dimensioni sono più costose rispetto alle operazioni per i documenti di piccole dimensioni. Idealmente, progettare l'applicazione e i flussi di lavoro in modo che le dimensioni dell'elemento siano di circa 1 KB o un ordine o una grandezza simili. Per le applicazioni sensibili alla latenza, è consigliabile evitare elementi di grandi dimensioni. I documenti multi-MB rallentano l'applicazione.
Passaggi successivi
Per altre informazioni sulla progettazione dell'applicazione per scalabilità e prestazioni elevate, vedere l'articolo relativo a partizionamento e ridimensionamento in Azure Cosmos DB.
Si sta tentando di pianificare la capacità per una migrazione ad Azure Cosmos DB? È possibile usare le informazioni del cluster di database esistente per la pianificazione della capacità.
- Se si conosce solo il numero di vCore e server nel cluster di database esistente, leggere le informazioni sulla stima delle unità richieste con vCore o vCPU
- Se si conosce la frequenza delle richieste tipiche per il carico di lavoro corrente del database, leggere le informazioni sulla stima delle unità richieste con lo strumento di pianificazione della capacità di Azure Cosmos DB