# REL05-BP05 Impostazione dei timeout dei client
<a name="rel_mitigate_interaction_failure_client_timeouts"></a>

 Imposta i timeout in modo appropriato, verificali sistematicamente e non fare affidamento sui valori predefiniti poiché sono generalmente troppo alti. 

 Questa best practice si applica al lato client, o al mittente, della richiesta. 

 Imposta sia un timeout di connessione che un timeout di richiesta su qualsiasi chiamata remota e, generalmente, su qualsiasi chiamata tra i processi. Molti framework offrono funzionalità di timeout integrate, ma fai attenzione perché molti hanno valori predefiniti infiniti o troppo alti. Un valore troppo elevato riduce l'utilità del timeout perché le risorse continuano a essere consumate mentre il client attende che si verifichi il timeout. Un valore troppo basso può generare un aumento del traffico sul back-end e una maggiore latenza perché vengono ritentate troppe richieste. In alcuni casi, questo può portare a interruzioni complete perché tutte le richieste vengono ritentate. 

 Per ulteriori informazioni su come Amazon utilizza timeout, nuovi tentativi e backoff con jitter, consulta la [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). 

 **Livello di rischio associato se questa best practice non fosse adottata:** Alta 

## Guida all'implementazione
<a name="implementation-guidance"></a>
+  Imposta sia un timeout di connessione che un timeout di richiesta su qualsiasi chiamata remota e, generalmente, su qualsiasi chiamata tra i processi. Molti framework offrono funzionalità di timeout integrate, ma fai attenzione perché molti hanno valori predefiniti infiniti o troppo alti. Un valore troppo elevato riduce l'utilità del timeout perché le risorse continuano a essere consumate mentre il client attende che si verifichi il timeout. Un valore troppo basso può generare un aumento del traffico sul back-end e una maggiore latenza perché vengono ritentate troppe richieste. In alcuni casi, questo può portare a interruzioni complete perché tutte le richieste vengono ritentate. 
  +  [AWS SDK: Retries and Timeouts (SDK AWS: nuovi tentativi e timeout)](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html) 

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

 **Documenti correlati:** 
+  [AWS SDK: Retries and Timeouts (SDK AWS: nuovi tentativi e timeout)](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html) 
+  [Amazon API Gateway: throttling delle richieste API per migliorare le prestazioni](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 
+  [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) 
+  [The Amazon Builders' Library: Timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) 

 **Video correlati:** 
+  [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Presentazione della libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)