# REL05-BP05 Définir les délais d'attente du client
<a name="rel_mitigate_interaction_failure_client_timeouts"></a>

 Définissez les délais d'expiration de manière appropriée, vérifiez-les systématiquement et ne comptez pas sur les valeurs par défaut, car elles sont généralement trop élevées. 

 Cette bonne pratique s'applique coté client, ou expéditeur, de la requête. 

 Définissez un délai de connexion et un délai de demande pour tout appel à distance et, plus généralement, pour tout appel entre processus. De nombreux cadres offrent des fonctionnalités de délai d'expiration intégrées. Toutefois, restez prudent, car beaucoup d'entre elles ont des valeurs par défaut infinies ou trop élevées. Une valeur trop élevée réduit l'utilité du délai d'attente, car les ressources continuent d'être consommées pendant que le client attend l'expiration du délai. Une valeur trop faible peut générer un trafic accru sur le backend et une latence accrue en raison du trop grand nombre de demandes relancées. Dans certains cas, cela peut entraîner des interruptions complètes, car toutes les demandes font l'objet d'une nouvelle tentative. 

 Pour en savoir plus sur l'utilisation par Amazon des délais d'attente, des nouvelles tentatives et de l'interruption avec instabilité, consultez [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card). 

 **Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit 

## Directives d'implémentation
<a name="implementation-guidance"></a>
+  Définissez un délai de connexion et un délai de demande pour tout appel à distance et, plus généralement, pour tout appel entre processus. De nombreux cadres offrent des fonctionnalités de délai d'expiration intégrées. Toutefois, restez prudent, car beaucoup d'entre elles ont des valeurs par défaut infinies ou trop élevées. Une valeur trop élevée réduit l'utilité du délai d'attente, car les ressources continuent d'être consommées pendant que le client attend l'expiration du délai. Une valeur trop faible peut générer un trafic accru sur le backend et une latence accrue en raison du trop grand nombre de demandes relancées. Dans certains cas, cela peut entraîner des interruptions complètes, car toutes les demandes font l'objet d'une nouvelle tentative. 
  +  [Kits SDK AWS : nouvelles tentatives et délais d'attente](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html) 

## Ressources
<a name="resources"></a>

 **Documents connexes :** 
+  [Kits SDK AWS : nouvelles tentatives et délais d'attente](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html) 
+  [Amazon API Gateway : limiter les demandes d'API pour un meilleur débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 
+  [Nouvelles tentatives après erreur et interruptions exponentielles dans AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) 
+  [L'Amazon Builders' Library : délais d'attente, nouvelles tentatives et backoff avec instabilité](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) 

 **Vidéos connexes :** 
+  [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)