Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Important
Il ne s’agit pas du Kit de développement logiciel (SDK) Java pour Azure Cosmos DB le plus récent. Vous devez mettre à niveau votre projet vers le Kit de développement logiciel (SDK) Java Azure Cosmos DB v4 , puis lire le guide des conseils sur les performances du Kit de développement logiciel (SDK) Java Azure Cosmos DB v4. Suivez les instructions du guide Migrate vers le Kit de développement logiciel (SDK) Java v4 Azure Cosmos DB et le guide Reactor vs RxJava pour la mise à niveau.
Les conseils en matière de performances de cet article concernent uniquement le Kit de développement logiciel (SDK) Java Asynchrone Azure Cosmos DB v2. Pour plus d’informations, consultez les notes de publication du Kit de développement logiciel (SDK) Java v2 Azure Cosmos DB Async, le référentiel Maven et le guide de résolution des problèmes du Kit de développement logiciel (SDK) Java v2 Azure Cosmos DB.
Important
Le 31 août 2024, le Kit de développement logiciel (SDK) Java Asynchrone Azure Cosmos DB v2.x sera mis hors service ; le KIT SDK et toutes les applications qui utilisent le Kit de développement logiciel (SDK) continueront à fonctionner ; Azure Cosmos DB cessera simplement de fournir une maintenance et une prise en charge supplémentaires pour ce Kit de développement logiciel (SDK). Nous vous recommandons de suivre les instructions ci-dessus pour migrer vers le kit de développement logiciel (SDK) Java Azure Cosmos DB v4.
Azure Cosmos DB est une base de données distribuée rapide et flexible qui peut être mise à l’échelle en toute transparence avec une latence et un débit garantis. Vous n’avez pas à apporter de modifications d’architecture majeures ou écrire de code complexe pour mettre à l’échelle votre base de données avec Azure Cosmos DB. Augmenter et réduire l'échelle est aussi simple que d'effectuer un appel d'API ou d'effectuer un appel de méthode SDK. Toutefois, étant donné qu’Azure Cosmos DB est accessible par le biais d’appels réseau, il existe des optimisations côté client que vous pouvez effectuer pour atteindre des performances optimales lors de l’utilisation du Kit de développement logiciel (SDK) Java Java asynchrone Azure Cosmos DB v2.
Par exemple, si vous vous demandez comment améliorer les performances de votre base de données, envisagez les options suivantes :
Networking
Mode de connexion : Utiliser le mode direct
La façon dont un client se connecte à Azure Cosmos DB a des implications importantes sur les performances, en particulier en termes de latence côté client. ConnectionMode est un paramètre de configuration clé disponible pour la configuration du client ConnectionPolicy. Pour azure Cosmos DB Async Java SDK v2, les deux ConnectionModes disponibles sont les suivants :
Le mode passerelle est pris en charge sur toutes les plateformes du Kit de développement logiciel (SDK) et il s’agit de l’option configurée par défaut. Si vos applications s’exécutent dans un réseau d’entreprise avec des restrictions de pare-feu strictes, le mode passerelle est le meilleur choix, car il utilise le port HTTPS standard et un seul point de terminaison. Toutefois, le compromis des performances est que le mode passerelle implique un tronçon réseau supplémentaire chaque fois que les données sont lues ou écrites dans Azure Cosmos DB. En raison de cela, le mode Direct offre de meilleures performances en raison de moins de tronçons réseau.
ConnectionMode est configuré pendant la construction de l’instance DocumentClient avec le paramètre ConnectionPolicy.
Kit de développement logiciel (SDK) Java asynchrone V2 (Maven com.microsoft.azure ::azure-cosmosdb)
public ConnectionPolicy getConnectionPolicy() {
ConnectionPolicy policy = new ConnectionPolicy();
policy.setConnectionMode(ConnectionMode.Direct);
policy.setMaxPoolSize(1000);
return policy;
}
ConnectionPolicy connectionPolicy = new ConnectionPolicy();
DocumentClient client = new DocumentClient(HOST, MASTER_KEY, connectionPolicy, null);
Colocaliser les clients dans la même région Azure pour de meilleures performances
Dans la mesure du possible, placez toutes les applications appelant Azure Cosmos DB dans la même région que la base de données Azure Cosmos DB. Pour une comparaison approximative, les appels à Azure Cosmos DB dans la même région s’effectuent en 1 à 2 ms, mais la latence entre les côtes Ouest et Est des États-Unis est >50 ms. Cette latence peut probablement varier d’une requête à l’autre, en fonction de l’itinéraire utilisé par la requête lorsqu’elle passe du client à la limite du centre de données Azure. Pour obtenir la latence la plus faible possible, l’application appelante doit être située dans la même région Azure que le point de terminaison Azure Cosmos DB configuré. Pour obtenir la liste des régions disponibles, voir Régions Azure.
Utilisation du Kit de développement logiciel (SDK
Installation du kit de développement logiciel (SDK) le plus récent
Les SDK Azure Cosmos DB sont constamment améliorés pour fournir des performances optimales. Consultez les pages Notes de publication du SDK Java v2 Azure Cosmos DB pour déterminer la version la plus récente du SDK et passer en revue les améliorations.
Utilisez un client singleton Azure Cosmos DB tout au long de la durée de vie de votre application
Chaque instance AsyncDocumentClient est thread-safe et effectue une gestion efficace des connexions et la mise en cache des adresses. Pour permettre une gestion efficace des connexions et de meilleures performances par AsyncDocumentClient, il est recommandé d’utiliser une seule instance d’AsyncDocumentClient par AppDomain pour la durée de vie de l’application.
Paramétrage de ConnectionPolicy
Par défaut, les requêtes Azure Cosmos DB en mode direct sont effectuées via TCP lors de l’utilisation du Kit de développement logiciel (SDK) Java Async Azure Cosmos DB v2. En interne, le Kit de développement logiciel (SDK) utilise une architecture en mode Direct spéciale pour gérer dynamiquement les ressources réseau et obtenir les meilleures performances.
Dans le SDK Java Async v2 d'Azure Cosmos DB, le mode Direct est le choix optimal pour améliorer les performances de la base de données avec la plupart des charges de travail.
- Vue d’ensemble du mode Direct
L’architecture côté client employée en mode Direct permet une utilisation prévisible du réseau et un accès multiplexé aux réplicas Azure Cosmos DB. Le diagramme ci-dessus montre comment le mode direct achemine les demandes du client vers des réplicas dans le back-end Azure Cosmos DB. L’architecture en mode direct alloue jusqu’à 10 canaux côté client par réplica de base de données. Un canal est une connexion TCP précédée d’une mémoire tampon de requêtes ayant une profondeur de 30 requêtes. Les canaux appartenant à un réplica sont alloués dynamiquement selon les besoins du point de terminaison de service du réplica. Lorsque l’utilisateur émet une requête en mode direct, TransportClient route la requête vers le point de terminaison de service approprié en fonction de la clé de partition. La file d’attente de requêtes met en mémoire tampon les demandes avant le point de terminaison de service.
Options de configuration ConnectionPolicy pour le mode direct
Pour commencer, utilisez les paramètres de configuration recommandés ci-dessous. Contactez l’équipe Azure Cosmos DB si vous rencontrez des problèmes sur cette rubrique particulière.
Si vous utilisez Azure Cosmos DB comme base de données de référence (autrement dit, la base de données est utilisée pour de nombreuses opérations de lecture de point et peu d’opérations d’écriture), il peut être acceptable de définir idleEndpointTimeout sur 0 (autrement dit, sans délai d’expiration).
Option de configuration Par défaut bufferPageSize 8192 connectionTimeout « PT1M » Délai d'expiration du canal inactif « PT0S » idleEndpointTimeout « PT1M10S » maxBufferCapacity 8388608 canauxMaxParPointDeConnexion 10 maxRequestsPerChannel 30 receiveHangDetectionTime « PT1M5S » requestExpiryInterval « PT5S » requestTimeout « PT1M » requestTimerResolution « PT0.5S » sendHangDetectionTime « PT10S » shutdownTimeout « PT15S »
Conseils de programmation pour le mode direct
Passez en revue l'article de résolution des problèmes du Kit de développement logiciel (SDK) Java Async v2 d'Azure Cosmos DB comme base pour résoudre les problèmes liés au Kit de développement logiciel (SDK).
Quelques conseils de programmation importants lors de l’utilisation du mode Direct :
Utilisez le multithreading dans votre application pour un transfert de données TCP efficace : après avoir effectué une demande, votre application doit s’abonner pour recevoir des données sur un autre thread. Ne pas le faire force une opération « semi-duplex » imprévue et les requêtes suivantes sont bloquées en attendant la réponse de la requête précédente.
Effectuer des charges de travail nécessitant beaucoup de ressources de calcul sur un thread dédié : pour des raisons similaires au conseil précédent, les opérations telles que le traitement complexe des données sont mieux placées dans un thread distinct. Une demande qui extrait des données d’un autre magasin de données (par exemple, si le thread utilise simultanément des magasins de données Azure Cosmos DB et Spark) peut rencontrer une latence accrue et il est recommandé de générer un thread supplémentaire qui attend une réponse de l’autre magasin de données.
- L’E/S réseau sous-jacent dans le Kit de développement logiciel (SDK) Java Asynchrone Azure Cosmos DB v2 est géré par Netty. Consultez ces conseils pour éviter les modèles de codage qui bloquent les threads d’E/S Netty.
Modélisation des données : le contrat SLA Azure Cosmos DB suppose que la taille du document est inférieure à 1 Ko. L’optimisation de votre modèle de données et de la programmation pour favoriser une taille de document plus petite entraîne généralement une diminution de la latence. Si vous avez besoin d’un stockage et d’une récupération de documents de plus de 1 Ko, l’approche recommandée consiste à lier des documents à des données dans Stockage Blob Azure.
Paramétrage des requêtes parallèles pour les collections partitionnés
Azure Cosmos DB Async Java SDK v2 prend en charge les requêtes parallèles, qui vous permettent d’interroger une collection partitionnée en parallèle. Pour plus d’informations, consultez les exemples de code liés à l’utilisation des kits SDK. Les requêtes parallèles sont conçues pour améliorer la latence et le débit des requêtes sur leur équivalent série.
Ajustement de setMaxDegreeOfParallelism :
Les requêtes parallèles interrogent plusieurs partitions en parallèle. Toutefois, les données d’une collection partitionnée individuelle sont extraites en série par rapport à la requête. Utilisez donc setMaxDegreeOfParallelism pour définir le nombre de partitions qui ont le maximum de chances d’atteindre la requête la plus performante, à condition que toutes les autres conditions système restent identiques. Si vous ne connaissez pas le nombre de partitions, vous pouvez utiliser setMaxDegreeOfParallelism pour définir un nombre élevé et le système choisit le minimum (nombre de partitions, entrée fournie par l’utilisateur) comme degré maximal de parallélisme.
Il est important de noter que les requêtes parallèles produisent les meilleurs avantages si les données sont réparties uniformément sur toutes les partitions par rapport à la requête. Si la collection partitionnée est structurée de telle manière que toutes ou la plupart des données retournées par une requête sont concentrées dans quelques partitions (dans le pire des cas, une seule partition), alors la performance de la requête sera limitée par ces partitions.
Réglage de setMaxBufferedItemCount :
La requête parallèle est conçue pour prérécupérer les résultats pendant que le lot actuel de résultats est traité par le client. La prérécupération permet d’améliorer la latence globale d’une requête. setMaxBufferedItemCount limite le nombre de résultats prérécupérés. Définir le paramètre setMaxBufferedItemCount sur le nombre de résultats renvoyés attendu (ou un nombre plus élevé) permet à la requête d’optimiser la pré-extraction.
La prérécupération fonctionne de la même façon, indépendamment du MaxDegreeOfParallelism, et il existe une mémoire tampon unique pour les données de toutes les partitions.
Implémenter un retrait aux intervalles spécifiés par getRetryAfterInMilliseconds
Pendant les tests de performance, vous devez augmenter la charge jusqu’à ce qu’un faible pourcentage de requêtes soit restreint. En cas de limitation, l’application client doit s’interrompre pour l’intervalle de nouvelle tentative spécifié sur le serveur. Respecter le délai de temporisation garantit que vous passez un temps d'attente minimal entre les nouvelles tentatives.
Effectuer un scale-out de votre charge de travail cliente
Si vous effectuez des tests à des niveaux de débit élevés (>50 000 RU/s), l’application cliente peut devenir le goulot d’étranglement en raison du plafonnement de l’ordinateur sur l’utilisation du processeur ou du réseau. Si vous atteignez ce point, vous pouvez continuer à augmenter le compte Azure Cosmos DB en augmentant la taille des instances de vos applications clientes sur plusieurs serveurs.
Utiliser l’adressage basé sur des noms
Utilisez l’adressage basé sur le nom, où les liens ont le format
dbs/MyDatabaseId/colls/MyCollectionId/docs/MyDocumentId, au lieu de SelfLinks (_self), qui ont le formatdbs/<database_rid>/colls/<collection_rid>/docs/<document_rid>pour éviter de récupérer les ResourceIds de toutes les ressources utilisées pour construire le lien. En outre, étant donné que ces ressources sont recréées (éventuellement avec le même nom), la mise en cache peut ne pas vous aider.Ajuster la taille de la page pour les requêtes/flux de lecture pour améliorer les performances
Lors de l’exécution d’une lecture en bloc de documents à l’aide de la fonctionnalité de flux de lecture (par exemple, readDocuments) ou lors de l’émission d’une requête SQL, les résultats sont retournés de manière segmentée si le jeu de résultats est trop volumineux. Par défaut, les résultats sont retournés en blocs de 100 éléments ou 1 Mo, selon la limite atteinte en premier.
Pour réduire le nombre d’allers-retours réseau requis pour récupérer tous les résultats applicables, vous pouvez augmenter la taille de la page à l’aide de l’en-tête de demande x-ms-max-item-count jusqu’à 1 000. Dans les cas où vous devez afficher seulement quelques résultats, par exemple, si votre interface utilisateur ou l’API d’application ne retourne que 10 résultats par heure, vous pouvez également réduire la taille de la page à 10 pour réduire le débit consommé pour les lectures et les requêtes.
Vous pouvez également définir la taille de page à l’aide de la méthode setMaxItemCount.
Utilisation du Scheduler approprié (éviter le vol de threads Netty E/S Eventloop)
Azure Cosmos DB Async Java SDK v2 utilise netty pour les E/S non bloquantes. Le Kit de développement logiciel (SDK) utilise un nombre fixe de threads d’E/S netty eventloop (autant de cœurs de processeur présents sur votre machine) pour l’exécution d’opérations d’E/S. L’Observable retourné par l’API émet le résultat sur l’un des threads netty d’eventloop d’E/S partagés. Il est donc important de ne pas bloquer les threads netty eventloop d’E/S partagés. Un travail intensif de l’UC ou le blocage de l’opération sur le thread netty eventloop d’E/S peut provoquer un interblocage ou réduire considérablement le débit du Kit de développement logiciel (SDK).
Par exemple, le code suivant exécute un travail intensif de l’UC sur le thread netty eventloop d’E/S :
Kit de développement logiciel (SDK) Java asynchrone V2 (Maven com.microsoft.azure ::azure-cosmosdb)
Observable<ResourceResponse<Document>> createDocObs = asyncDocumentClient.createDocument( collectionLink, document, null, true); createDocObs.subscribe( resourceResponse -> { //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(); });Une fois le résultat reçu, si vous souhaitez effectuer un travail intensif de l’UC sur le résultat, vous devez éviter de le faire sur le thread netty eventloop d’E/S. Vous pouvez fournir à la place votre propre Scheduler pour fournir votre propre thread pour l’exécution de votre travail.
Kit de développement logiciel (SDK) Java asynchrone V2 (Maven com.microsoft.azure ::azure-cosmosdb)
import rx.schedulers; Observable<ResourceResponse<Document>> createDocObs = asyncDocumentClient.createDocument( collectionLink, document, null, true); createDocObs.subscribeOn(Schedulers.computation()) subscribe( resourceResponse -> { // this is executed on threads provided by Scheduler.computation() // Schedulers.computation() should be used only when: // 1. The work is cpu intensive // 2. You are not doing blocking IO, thread sleep, etc. in this thread against other resources. veryCpuIntensiveWork(); });En fonction du type de votre travail, vous devez utiliser le planificateur RxJava existant approprié pour votre travail. Consultez ici
Schedulers.Pour plus d’informations, consultez la page GitHub pour azure Cosmos DB Async Java SDK v2.
Désactiver la journalisation de netty
La journalisation de la bibliothèque netty produit beaucoup d’informations et doit être désactivée (la suppression de la connexion dans la configuration peut être insuffisante) afin d’éviter des coûts de processeur supplémentaires. Si vous n’êtes pas en mode débogage, désactivez la journalisation de netty en même temps. Par conséquent, si vous utilisez log4j pour éliminer les coûts supplémentaires du processeur impliqués par l'utilisation de
org.apache.log4j.Category.callAppenders()netty, ajoutez la ligne suivante à votre base de code :org.apache.log4j.Logger.getLogger("io.netty").setLevel(org.apache.log4j.Level.OFF);Limite des ressources des fichiers ouverts du système d’exploitation
Certains systèmes Linux (par exemple Red Hat) ont une limite maximale du nombre de fichiers ouverts et donc du nombre total de connexions. Exécutez la commande suivante pour afficher les limites actuelles :
ulimit -aLe nombre de fichiers ouverts (nofile) doit être suffisamment grand pour avoir suffisamment de place pour la taille de votre pool de connexions configuré et d’autres fichiers ouverts par le système d’exploitation. Il peut être modifié pour permettre une plus grande taille des pools de connexion.
Ouvrir le fichier limits.conf :
vim /etc/security/limits.confAjoutez/modifiez les lignes suivantes :
* - nofile 100000
Stratégie d’indexation
Exclusion des chemins d’accès inutilisés de l’indexation pour des écritures plus rapides
La stratégie d’indexation d’Azure Cosmos DB vous permet de spécifier les chemins d’accès de document à inclure ou exclure de l’indexation à l’aide de chemins d’accès d’indexation (setIncludedPaths et setExcludedPaths). L’utilisation des chemins d’accès d’indexation peut offrir des performances d’écriture améliorées et réduire le stockage d’index pour les scénarios dans lesquels les modèles de requête sont connus d’avance, puisque les coûts d’indexation sont directement liés au nombre de chemins d’accès uniques indexés. Par exemple, le code suivant montre comment exclure toute une section des documents (également appelée sous-arborescence) de l’indexation à l’aide du caractère générique « * ».
Kit de développement logiciel (SDK) Java asynchrone V2 (Maven com.microsoft.azure ::azure-cosmosdb)
Index numberIndex = Index.Range(DataType.Number); numberIndex.set("precision", -1); indexes.add(numberIndex); includedPath.setIndexes(indexes); includedPaths.add(includedPath); indexingPolicy.setIncludedPaths(includedPaths); collectionDefinition.setIndexingPolicy(indexingPolicy);Pour plus d’informations, consultez Stratégies d’indexation d’Azure Cosmos DB.
Débit
Mesure et réglage pour réduire l’utilisation d’unités de requête par seconde
Azure Cosmos DB propose un riche ensemble d’opérations de base de données, y compris les requêtes hiérarchiques et relationnelles avec les fonctions définies par l’utilisateur, les procédures stockées et les déclencheurs, qui fonctionnent toutes au niveau des documents d’une collection de base de données. Le coût associé à chacune de ces opérations varie en fonction du processeur, des E/S et de la mémoire nécessaires à l’exécution de l’opération. Plutôt que de vous soucier de la gestion des ressources matérielles, vous pouvez considérer une unité de demande comme une mesure unique des ressources nécessaires à l’exécution des opérations de base de données et à la réponse à la requête de l’application.
Le débit est provisionné en fonction du nombre d’unités de requête défini pour chaque conteneur. La consommation d’unités de requête est évaluée en fonction d’un taux par seconde. Les applications qui dépassent le taux d’unités de requête configuré pour le conteneur associé sont limitées jusqu’à ce que le taux soit inférieur au niveau configuré pour le conteneur. Si votre application requiert un niveau de débit plus élevé, vous pouvez augmenter le débit en provisionnant des unités de requête supplémentaires.
La complexité d’une requête a un impact sur le nombre d’unités de requête consommées pour une opération. Le nombre de prédicats, la nature des prédicats, le nombre de fonctions définies par l’utilisateur et la taille du jeu de données sources ont tous une influence sur le coût des opérations de requête.
Pour mesurer la surcharge de toute opération (création, mise à jour ou suppression), inspectez l’en-tête x-ms-request-charge afin de mesurer le nombre d’unités de requête consommées par ces opérations. Vous pouvez également examiner la propriété RequestCharge équivalente dans ResourceResponse<T> ou FeedResponse<T>.
Kit de développement logiciel (SDK) Java asynchrone V2 (Maven com.microsoft.azure ::azure-cosmosdb)
ResourceResponse<Document> response = asyncClient.createDocument(collectionLink, documentDefinition, null, false).toBlocking.single(); response.getRequestCharge();Les frais de la requête retournée dans cet en-tête correspondent à une fraction du débit provisionné. Par exemple, si vous avez provisionné 2000 RU/s et si la requête précédente retourne 1 000 documents de 1 Ko, le coût de l’opération est de 1 000. Par conséquent, en une seconde, le serveur honore uniquement deux requêtes avant de limiter le taux de requêtes suivantes. Pour plus d’informations, consultez Unités de requête et la calculatrice d’unités de requête.
Gestion de la limitation du taux/du taux de requêtes trop élevé
Lorsqu’un client tente de dépasser le débit réservé pour un compte, les performances au niveau du serveur ne sont pas affectées et la capacité de débit n’est pas utilisée au-delà du niveau réservé. Le serveur met fin à la requête de manière préventive avec RequestRateTooLarge (code d’état HTTP 429) et il retourne l’en-tête x-ms-retry-after-ms indiquant la durée, en millisecondes, pendant laquelle l’utilisateur doit attendre avant de réessayer.
HTTP Status 429, Status Line: RequestRateTooLarge x-ms-retry-after-ms :100Les kits de développement logiciel (SDK) interceptent tous implicitement cette réponse, respectent l’en-tête retry-after spécifiée par le serveur, puis relancent la requête. La tentative suivante réussira toujours, sauf si plusieurs clients accèdent simultanément à votre compte.
Si plusieurs clients fonctionnent de façon cumulative au-dessus du taux de requête, le nombre de nouvelles tentatives par défaut défini sur 9 en interne par le client peut ne pas suffire ; dans ce cas, le client lève une exception DocumentClientException avec le code d’état 429 à l’application. Le nombre de nouvelles tentatives par défaut peut être modifié à l’aide de setRetryOptions sur l’instance ConnectionPolicy. Par défaut, DocumentClientException avec le code d’état 429 est retourné après un délai d’attente cumulé de 30 secondes si la requête continue à fonctionner au-dessus du taux de requête. Cela se produit même lorsque le nombre de nouvelles tentatives actuel est inférieur au nombre maximal de nouvelles tentatives, qu’il s’agisse de la valeur par défaut de 9 ou d’une valeur définie par l’utilisateur.
Alors que le comportement de nouvelle tentative automatique permet d’améliorer la résilience et la facilité d’utilisation pour la plupart des applications, il peut se révéler contradictoire lors de l’exécution de tests de performances, en particulier lors de la mesure de la latence. La latence client observée atteindra un pic si l’expérience atteint la limite de serveur et oblige le kit de développement logiciel (SDK) client à effectuer une nouvelle tentative en silence. Pour éviter des pics de latence lors des expériences de performances, mesurez la charge renvoyée par chaque opération et assurez-vous que les requêtes fonctionnent en dessous du taux de requête réservé. Pour plus d’informations, consultez Unités de requête.
Conception de documents plus petits pour un débit plus élevé
Les frais de requête (le coût de traitement de requête) d’une opération donnée sont directement liés à la taille du document. Des opérations sur des documents volumineux coûtent plus cher que des opérations sur de petits documents.
Étapes suivantes
Pour en savoir plus sur la conception de votre application pour une mise à l’échelle et des hautes performances, consultez Partitionnement et mise à l’échelle dans Azure Cosmos DB.