Diagnostiquer et résoudre les exceptions de dépassement de délai de demande avec le SDK Java v4 Azure Cosmos DB

S’APPLIQUE À : NoSQL

L'erreur HTTP 408 se produit si le SDK n'a pas pu terminer la demande avant l'expiration du délai d'attente.

Étapes de dépannage

La liste suivante répertorie les causes connues et les solutions pour les exceptions de dépassement de délai de demande.

Stratégie de délai d’expiration de bout en bout

Il existe des scénarios dans lesquels des erreurs de délai d’expiration réseau 408 se produisent, même quand toutes les solutions préemptives mentionnées ci-dessus ont été implémentées. La meilleure pratique générale pour réduire la latence de fin, ainsi que pour améliorer la disponibilité dans ces scénarios, est d’implémenter une stratégie de délai d’expiration de bout en bout. La latence de fin est diminuée avec le mode Fail-fast et les unités de requête et les coûts de calcul côté client sont réduits en arrêtant les nouvelles tentatives après le délai d’expiration. La durée de délai d’expiration peut être définie sur CosmosItemRequestOptions. Les options peuvent ensuite être passées aux requêtes envoyées à Azure Cosmos DB :

CosmosEndToEndOperationLatencyPolicyConfig endToEndOperationLatencyPolicyConfig = new CosmosEndToEndOperationLatencyPolicyConfigBuilder(Duration.ofSeconds(1)).build();
CosmosItemRequestOptions options = new CosmosItemRequestOptions();
options.setCosmosEndToEndOperationLatencyPolicyConfig(endToEndOperationLatencyPolicyConfig);
container.readItem("id", new PartitionKey("pk"), options, TestObject.class);

Problèmes existants

Si vous constatez que les requêtes sont bloquées pendant une durée plus longue ou que le délai est plus fréquemment dépassé, mettez à niveau le Kit de développement logiciel (SDK) Java v4 vers la dernière version. REMARQUE : Nous vous recommandons vivement d’utiliser la version 4.18.0 ou une version supérieure. Pour plus d’informations, consultez les Notes de publication du Kit de développement logiciel (SDK) Java v4.

Utilisation élevée du processeur

L'utilisation élevée du processeur est le cas le plus courant. Pour une latence optimale, l'utilisation du processeur doit être d'environ 40 %. Utilisez 10 secondes comme intervalle pour superviser l'utilisation maximale (non moyenne) du processeur. Les pics d'utilisation du processeur sont plus courants avec les requêtes entre partitions où il peut y avoir plusieurs connexions pour une seule requête.

Solution :

L'application cliente qui utilise le SDK doit faire l'objet d'un scale-up ou d'un scale-out.

Limitation de la connexion

La limitation de la connexion peut se produire en raison d’une Limite de connexion sur un ordinateur hôte ou d’une insuffisance de ports Azure SNAT (PAT).

Limite de connexion sur un ordinateur hôte

Certains systèmes Linux, tels que Red Hat, ont une limite supérieure quant au nombre total de fichiers ouverts. Les sockets dans Linux étant implémentés en tant que fichiers, ce nombre limite aussi le nombre total de connexions. Exécutez la commande suivante :

ulimit -a

Solution :

La quantité maximale de fichiers ouverts autorisée, qui sont identifiés comme « nofile », doit être d’au moins 10 000. Pour plus d’informations, consultez les conseils sur les performances associés au kit SDK Java v4 Azure Cosmos DB.

La disponibilité du socket ou du port peut être faible

Quand ils s’exécutent dans Azure, les clients qui utilisent le SDK Java peuvent rencontrer un problème d’épuisement de ports Azure SNAT (PAT).

Solution 1 :

Si vous utilisez des machines virtuelles Azure, suivez le guide consacré à l'insuffisance de ports SNAT.

Solution 2 :

Si vous utilisez Azure App Service, suivez le guide de dépannage des erreurs de connexion et utilisez les diagnostics App Service.

Solution 3 :

Si vous utilisez Azure Functions, suivez la recommandation Azure Functions de gestion des clients statiques ou des singletons pour tous les services impliqués (y compris Cosmos DB). Vérifiez les limites de service en fonction du type et de la taille de votre hébergement Function App.

Solution 4 :

Si vous utilisez un proxy HTTP, vérifiez qu’il peut prendre en charge le nombre de connexions configuré dans SDK GatewayConnectionConfig. Sinon, vous serez confronté à des problèmes de connexion.

Créer plusieurs instances clientes

La création de plusieurs instances clientes peut entraîner des problèmes de conflit et de dépassement de délai de connexion.

Solution 1 :

Suivez les conseils en lien avec les performances et utilisez une seule instance CosmosClient pour l’ensemble de l’application.

Solution 2 :

S’il n’est pas possible d’avoir CosmosClient singleton dans une application, nous vous recommandons d’utiliser le partage de connexion entre plusieurs clients Azure Cosmos DB via cette API connectionSharingAcrossClientsEnabled(true) dans CosmosClient. Si vous avez plusieurs instances du client Cosmos dans la même machine virtuelle Java qui interagissent avec plusieurs comptes Azure Cosmos DB, l’activation de cette option permet le partage de connexion en mode Direct, si possible entre les instances du client Azure Cosmos DB. Notez que lorsque vous définissez cette option, la configuration de la connexion (par exemple, configuration du délai d’attente du socket, configuration du délai d’inactivité) du premier client instancié sera utilisée pour toutes les autres instances du client.

Clé de partition à chaud

Azure Cosmos DB répartit le débit global approvisionné de manière uniforme entre les partitions physiques. Lorsqu'il existe une partition à chaud, une ou plusieurs clés de partition logique sur une partition physique consomment la totalité des unités de requête par seconde (RU/s) de la partition physique. Dans le même temps, les RU/s d'autres partitions physiques ne sont plus utilisées. Par conséquent, le nombre total de RU/s consommées sera inférieur au nombre global de RU/s approvisionnées dans la base de données ou le conteneur, mais vous verrez toujours une limitation (429s) sur les demandes par rapport à la clé de partition logique à chaud. Utilisez la métrique Consommation d’unités de requête normalisée pour voir si la charge de travail rencontre une partition à chaud.

Solution :

Choisissez une clé de partition appropriée qui répartit uniformément le volume de demandes et le stockage. Découvrez comment changer votre clé de partition.

Degré élevé de simultanéité

L'application atteint un niveau élevé de simultanéité, ce qui peut entraîner des conflits sur le canal.

Solution :

L'application cliente qui utilise le SDK doit faire l'objet d'un scale-up ou d'un scale-out.

Demandes ou réponses volumineuses

Des demandes ou réponses volumineuses peuvent entraîner un blocage en tête de ligne sur le canal et exacerber les conflits, même avec un degré relativement faible de simultanéité.

Solution :

L'application cliente qui utilise le SDK doit faire l'objet d'un scale-up ou d'un scale-out.

Le taux d'échec est compris dans le contrat de niveau de service Azure Cosmos DB

L’application doit être en mesure de gérer les défaillances temporaires et de réessayer si nécessaire. Il n'y a pas de nouvelle tentative pour les exceptions 408 car, lors de la création de chemins, il est impossible de savoir si le service a créé l'élément ou non. Le renvoi d’un même élément pour la création entraîne une exception de conflit. La logique métier des applications utilisateur peut avoir une logique personnalisée pour gérer les conflits, ce qui permet d'éviter l'ambiguïté d'un élément existant par rapport à un conflit suite à une nouvelle tentative de création.

Le taux d'échec n'est pas conforme au contrat de niveau de service Azure Cosmos DB

Contactez Support Azure.

Étapes suivantes

• Diagnostiquer et résoudre des problèmes lors de l'utilisation du SDK Java v4 Azure Cosmos DB.
• Découvrez les recommandations relatives aux performances pour Java v4.