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à.
# Elaborazione e tempistica dei messaggi di Amazon SQS
Questo argomento fornisce una guida completa sull'ottimizzazione della velocità e dell'efficienza della gestione dei messaggi in Amazon SQS, comprese le strategie per l'elaborazione tempestiva dei messaggi, la selezione della migliore modalità di polling e la configurazione di polling lunghi per migliorare le prestazioni.
****Argomenti****
+ [Elaborazione tempestiva dei messaggi in Amazon SQS](best-practices-processing-messages-timely-manner.md)
+ [Configurazione di sondaggi lunghi in Amazon SQS](best-practices-setting-up-long-polling.md)
+ [Utilizzo della modalità di polling appropriata in Amazon SQS](best-practices-using-appropriate-polling-mode.md)
# Elaborazione tempestiva dei messaggi in Amazon SQS
Le impostazioni del timeout visibilità dipendono da quanto tempo richiede la tua applicazione per elaborare ed eliminare un messaggio. Ad esempio, se la tua applicazione richiede 10 secondi per elaborare un messaggio e imposti il timeout visibilità su 15 minuti, è necessario attendere un tempo relativamente lungo per tentare di elaborare il messaggio di nuovo se il precedente tentativo di elaborazione ha esito negativo. In alternativa, se la tua applicazione richiede 10 secondi per elaborare un messaggio, ma imposti il timeout visibilità su solo 2 secondi, un duplicato del messaggio verrà ricevuto da un altro consumatore mentre il consumatore originale sta ancora lavorando sul messaggio.
Per garantire il tempo sufficiente per elaborare un messaggio, utilizza una delle seguenti strategie:
+ Se sai (o puoi ragionevolmente stimare) la quantità di tempo necessaria per elaborare un messaggio, estendi il *timeout visibilità* del messaggio per il tempo massimo richiesto per elaborare ed eliminare il messaggio. Per ulteriori informazioni, consulta [Configurazione del timeout di visibilità](sqs-visibility-timeout.md#configuring-visibility-timeout).
+ Se non sai quanto tempo sia necessario per elaborare un messaggio, crea un *heartbeat* per il processo del consumatore: specifica il timeout visibilità iniziale (ad esempio, 2 minuti) e poi, se il consumatore lavora ancora sul messaggio, continua a estendere il timeout visibilità di 2 minuti ogni minuto.
**Importante**
Il timeout massimo di visibilità è di 12 ore dal momento in cui Amazon SQS riceve la richiesta `ReceiveMessage`. L'estensione del timeout di visibilità non reimposta il massimo di 12 ore.
Inoltre, potresti non essere in grado di impostare il timeout per un singolo messaggio per tutte le 12 ore (ad esempio 43.200 secondi) trascorse dalla richiesta `ReceiveMessage` che avvia il timer. Ad esempio, se si riceve un messaggio e si imposta immediatamente il limite massimo di 12 ore inviando una chiamata `ChangeMessageVisibility` della durata di 43.200 secondi, è probabile che la chiamata abbia esito negativo. Tuttavia, l'utilizzo di un valore di 43.195 secondi funzionerà a meno che non vi sia un ritardo significativo tra la richiesta del messaggio tramite `ReceiveMessage` e l'aggiornamento del timeout di visibilità. Se il consumatore ha bisogno di più di 12 ore, prendere in considerazione l'utilizzo di Step Functions.
# Configurazione di sondaggi lunghi in Amazon SQS
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).
# Utilizzo della modalità di polling appropriata in Amazon SQS
+ Il long polling consente di utilizzare messaggi dalla coda Amazon SQS non appena diventano disponibili.
+ Per ridurre il costo di utilizzo di Amazon SQS e ridurre il numero di ricezioni vuote in una coda vuota (risposte all'operazione `ReceiveMessage` che non restituisce messaggi), abilita il long polling. Per ulteriori informazioni, consulta [Long Polling Amazon SQS](sqs-short-and-long-polling.md).
+ Per incrementare l'efficienza durante il polling per più thread con più ricezioni, riduci il numero di thread.
+ Il polling lungo è preferibile al polling breve nella maggior parte dei casi.
+ Lo short polling restituisce risposte immediatamente, anche se la coda Amazon SQS di cui è stato eseguito il polling è vuota.
+ Per soddisfare i requisiti di un'applicazione che richiede risposte immediate per la richiesta `ReceiveMessage`, utilizza il polling a breve.
+ Il polling breve viene fatturato allo stesso costo del polling lungo.