Partager via

Diagnostiquer et résoudre les exceptions de dépassement de délai de demande avec le SDK .NET

  • Article

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.

Il est important de s’assurer que la conception de l’application suit notre guide pour concevoir des applications résilientes avec des kits SDK Azure Cosmos DB pour vous assurer qu’elle réagit correctement à différentes conditions réseau. Votre application doit permettre l’exécution de nouvelles tentatives pour les erreurs liées aux expirations de délai, car celles-ci sont normalement attendues dans un système distribué.

Au moment de l’évaluation du cas pour les erreurs de délai d’expiration :

  • Quel est l’impact mesuré en termes de volume d’opérations affectées par rapport aux opérations qui se déroulent correctement ? Est-ce que cela entre dans le cadre des contrats SLA de service ?
  • La latence ou la disponibilité P99 sont-elles affectées ?
  • Les échecs affectent-ils toutes les instances de votre application ou uniquement un sous-ensemble ? Lorsque le problème est réduit à un sous-ensemble d’instances, il s’agit généralement d’un problème lié à ces instances.

Personnaliser le délai d'expiration sur le Kit de développement logiciel (SDK) .NET Azure Cosmos

Le Kit de développement logiciel (SDK) offre deux alternatives distinctes pour contrôler les délais d’expiration, chacune avec une étendue différente.

Délais d’attente au niveau de la requête

La CosmosClientOptions.RequestTimeout configuration (ou ConnectionPolicy.RequestTimeout pour le SDK v2) vous permet de définir un délai d’attente pour la requête réseau après que la requête a quitté le Kit de développement logiciel (SDK) et se trouve sur le réseau, jusqu’à la réception d’une réponse.

La configuration CosmosClientOptions.OpenTcpConnectionTimeout (ou ConnectionPolicy.OpenTcpConnectionTimeout pour le SDK v2) vous permet de définir un délai d’attente pour le temps consacré à l’ouverture d’une connexion initiale. Une fois la connexion ouverte, les requêtes suivantes utilisent la connexion.

Une opération lancée par un utilisateur peut couvrir plusieurs requêtes réseau (par exemple, les nouvelles tentatives). Ces deux configurations sont par requête, et non de bout en bout pour une opération.

CancellationToken

Toutes les opérations asynchrones dans le Kit de développement logiciel (SDK) ont un paramètre CancellationToken facultatif. Ce paramètre CancellationToken est utilisé tout au long de l’opération, sur toutes les requêtes réseau et nouvelles tentatives. Entre les requêtes réseau, le paramètre CancellationToken peut être vérifié et une opération annulée si le jeton associé a expiré. Le paramètre CancellationToken doit être utilisé pour définir un délai d'expiration approximatif sur l'étendue de l'opération.

Notes

Le paramètre CancellationToken est un mécanisme par lequel la bibliothèque vérifie l'annulation lorsqu'elle ne provoque pas d'état non valide. L'annulation de l'opération peut ne pas intervenir au moment même où le délai défini est écoulé. Une fois le délai écoulé, l'annulation peut en effet n'intervenir que lorsque les conditions de sécurité sont réunies.

É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.

CosmosOperationCanceledException

Ce type d’exception est courant lorsque votre application transmet CancellationTokens aux opérations du Kit de développement logiciel (SDK). Le Kit de développement logiciel (SDK) vérifie l’état entre CancellationToken et les nouvelles tentatives et, si le CancellationToken est annulé, il abandonne l’opération actuelle avec cette exception.

Le Message / ToString() de l’exception indique également l’état de votre CancellationToken via Cancellation Token has expired: true, et contient également des diagnostics qui donnent le contexte de l’annulation pour les demandes impliquées.

Ces exceptions sont sécurisées pour effectuer une nouvelle tentative et peuvent être traitées comme des délais d’attente du point de vue des nouvelles tentatives.

Solution

Vérifiez le temps configuré dans votre CancellationToken, assurez-vous qu’il est supérieur à votre RequestTimeout et à CosmosClientOptions.OpenTcpConnectionTimeout (si vous utilisez le mode direct). Si le temps disponible dans le CancellationToken est inférieur aux délais d’attente configurés et que le Kit de développement logiciel (SDK) rencontre des problèmes de connectivité temporaires, le Kit de développement logiciel (SDK) ne peut pas effectuer de nouvelle tentative et lève CosmosOperationCanceledException.

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.

Les délais d'attente contiendront les Diagnostics, qui contiennent :

"systemHistory": [
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
...
]
  • Si les valeurs cpu dépassent 70 %, le délai d’expiration est probablement provoqué par un épuisement du processeur. Dans ce cas, la solution consiste à examiner la source de l’utilisation élevée du processeur et à la réduire, ou à augmenter les ressources de la machine.
  • Si les nœuds threadInfo/isThreadStarving ont des valeurs True, la cause en est le manque de threads. Dans ce cas, la solution consiste à étudier la ou les sources de la privation de thread (threads potentiellement verrouillés) ou à augmenter les ressources de la ou des machines.
  • Si le délai dateUtc entre les mesures n’est pas d’environ 10 secondes, cela indique également de la contention dans le pool de threads. Le processeur est mesuré par une tâche indépendante qui est mise en file d’attente dans le pool de threads toutes les 10 secondes. Si le temps entre les mesures est plus long, cela indique que les tâches asynchrones ne peuvent pas être traitées en temps voulu. Les scénarios les plus courants sont les appels bloquants sur du code asynchrone dans le code de l’application.

Solution

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

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

Quand ils s’exécutent dans Azure, les clients qui utilisent le kit SDK .NET 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 ConnectionPolicy. 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. Les diagnostics contiennent deux propriétés pertinentes :

{
    "NumberOfClientsCreated":X,
    "NumberOfActiveClients":Y,
}

NumberOfClientsCreated suit le nombre de fois qu’un CosmosClient a été créé dans le même domaine d’application et NumberOfActiveClients effectue le suivi des clients actifs (non supprimés). En principe, si le modèle singleton est suivi, X doit correspondre au nombre de comptes utilisant l’application et X doit être égal à Y.

Si X supérieur à Y, cela signifie que l’application crée et supprime des instances clientes. Cela peut entraîner une contention de connexion et/ou une contention du processeur.

Solution

Suivez les conseils relatifs aux performances et utilisez une seule instance CosmosClient par compte pour l’ensemble du processus. Évitez de créer et de supprimer des clients.

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 kit de développement logiciel (SDK) .NET Azure Cosmos DB.
  • Découvrez les recommandations relatives aux performances pour .NET V3 et .NET V2.