Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Configurazione di sondaggi lunghi in Amazon SQS
<a name="best-practices-setting-up-long-polling"></a>

Quando il tempo di attesa per l'azione dell'API `[ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)` è superiore a 0, viene attivato un *polling lungo*. Il tempo massimo di attesa per il polling lungo è di 20 secondi. Il polling prolungato aiuta a ridurre i costi di utilizzo di Amazon SQS riducendo il numero di risposte vuote (quando non ci sono messaggi disponibili per `ReceiveMessage` una richiesta) e di false risposte vuote (quando i messaggi sono disponibili ma non sono inclusi in una risposta). Per ulteriori informazioni, consulta [Polling brevi e lunghi di Amazon SQS](sqs-short-and-long-polling.md).

Per garantire l'elaborazione ottimale del messaggio, utilizza le seguenti strategie:
+ Nella maggior parte dei casi, è possibile impostare il tempo di attesa `ReceiveMessage` su 20 secondi. Se 20 secondi è troppo lungo per la tua applicazione, imposta un tempo di attesa `ReceiveMessage` inferiore (minimo 1 secondo). Se non utilizzi un AWS SDK per accedere ad Amazon SQS o se configuri AWS un SDK per avere un tempo di attesa più breve, potresti dover modificare il tuo client Amazon SQS per consentire richieste più lunghe o utilizzare un tempo di attesa più breve per lunghi polling.
+ Se implementi il long polling per più code, utilizza un thread per ogni coda invece di un singolo thread per tutte le code. L'utilizzo di un singolo thread per ogni coda consente alla tua applicazione di elaborare i messaggi in ognuna delle code non appena sono disponibili, mentre l'utilizzo di un singolo thread per il polling di più code potrebbe causare la non disponibilità della tua applicazione per elaborare i messaggi disponibili in altre code, mentre l'applicazione attende (fino a 20 secondi) la coda che non ha messaggi disponibili.

**Importante**  
Per evitare errori HTTP, assicurarsi che il timeout della risposta HTTP per le richieste `ReceiveMessage` sia più lungo del parametro `WaitTimeSeconds`. Per ulteriori informazioni, consulta [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html).