As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Tempo e processamento de mensagens do Amazon SQS
Este tópico fornece orientação abrangente sobre como otimizar a velocidade e a eficiência do gerenciamento de mensagens no Amazon SQS, incluindo estratégias para processamento oportuno de mensagens, seleção do melhor modo de votação e configuração de sondagem longa para melhorar o desempenho.
****Tópicos****
+ [Processar mensagens em tempo hábil no Amazon SQS](best-practices-processing-messages-timely-manner.md)
+ [Configurar a sondagem longa no Amazon SQS](best-practices-setting-up-long-polling.md)
+ [Usar o modo de sondagem apropriado no Amazon SQS](best-practices-using-appropriate-polling-mode.md)
# Processar mensagens em tempo hábil no Amazon SQS
Definir o tempo limite de visibilidade depende do tempo de que o seu aplicativo precisa para processar e excluir uma mensagem. Por exemplo, se seu aplicativo exigir 10 segundos para processar uma mensagem e você definir o tempo limite de visibilidade como 15 minutos, deverá esperar por um tempo relativamente longo para tentar processar a mensagem novamente se a tentativa de processamento anterior falhar. Como alternativa, se o aplicativo exigir 10 segundos para processar uma mensagem, mas você definir o tempo limite de visibilidade como apenas 2 segundos, uma mensagem duplicada será recebida por outro consumidor enquanto o consumidor original ainda estiver trabalhando na mensagem.
Para garantir que haja tempo suficiente para processar mensagens, use uma das seguintes estratégias:
+ Se você souber (ou puder razoavelmente estimar) quanto tempo leva para processar uma mensagem, amplie o *tempo limite de visibilidade* da mensagem para o máximo de tempo necessário para processar e excluir a mensagem. Para obter mais informações, consulte [Configurar tempo limite de visibilidade](sqs-visibility-timeout.md#configuring-visibility-timeout).
+ Se você não souber quanto tempo leva para processar uma mensagem, crie uma *pulsação* para o processo do consumidor: especifique o tempo limite de visibilidade inicial (por exemplo, 2 minutos) e, desde que o consumidor ainda funcione na mensagem, continue estendendo o tempo limite de visibilidade em 2 minutos a cada minuto.
**Importante**
O tempo limite de visibilidade máximo é de 12 horas a partir do momento em que o Amazon SQS recebe `ReceiveMessage`. Estender o tempo limite de visibilidade não redefine o período máximo de 12 horas.
Além disso, talvez você não consiga definir o tempo limite em uma mensagem individual para as 12 horas completas (por exemplo, 43.200 segundos), pois a solicitação de `ReceiveMessage` inicia o temporizador. Por exemplo, se você receber uma mensagem e definir imediatamente o máximo de 12 horas enviando uma chamada de `ChangeMessageVisibility` com `VisibilityTimeout` igual a 43.200 segundos, provavelmente ocorrerá uma falha. No entanto, usar um valor de 43.195 segundos funcionará, a menos que haja um atraso significativo entre a solicitação da mensagem via `ReceiveMessage` e a atualização do tempo limite de visibilidade. Se o consumidor precisar de mais de 12 horas, considere usar o Step Functions.
# Configurar a sondagem longa no Amazon SQS
Quando o tempo de espera da ação da API `[ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)` é maior do que 0, a *sondagem longa* está em vigor. O tempo máximo de espera de sondagem longa é de 20 segundos. A sondagem longa ajuda a reduzir o custo do uso do Amazon SQS ao reduzir o número de respostas vazias (quando não há mensagens disponíveis para `ReceiveMessage` uma solicitação) e falsas respostas vazias (quando as mensagens estão disponíveis, mas não estão incluídas em uma resposta). Para obter mais informações, consulte [Sondagem curta e longa do Amazon SQS](sqs-short-and-long-polling.md).
Para garantir o processamento ideal de mensagens, use as seguintes estratégias:
+ Na maioria dos casos, você pode definir o tempo de espera de `ReceiveMessage` como 20 segundos. Se 20 segundos for muito longo para seu aplicativo, defina um tempo de espera `ReceiveMessage` mais curto (no mínimo, 1 segundo). Se você não usa um AWS SDK para acessar o Amazon SQS, ou se configura AWS um SDK para ter um tempo de espera menor, talvez seja necessário modificar seu cliente Amazon SQS para permitir solicitações mais longas ou usar um tempo de espera menor para pesquisas longas.
+ Se você implementar a sondagem longa para várias filas, use um thread para cada fila, em vez de um único thread para todas as filas. O uso de um único thread para cada fila permite que seu aplicativo processe as mensagens em cada uma das filas conforme se tornam disponíveis, enquanto o uso de um único thread para sondar várias filas pode fazer com que seu aplicativo não possa processar as mensagens disponíveis em outras filas enquanto o aplicativo aguarda (até 20 segundos) por uma fila que não tem mensagens disponíveis.
**Importante**
Para evitar erros de HTTP, certifique-se de que o tempo limite da resposta HTTP para solicitações `ReceiveMessage` é maior do que o parâmetro `WaitTimeSeconds`. Para obter mais informações, consulte [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html).
# Usar o modo de sondagem apropriado no Amazon SQS
+ A sondagem longa permite que você consuma mensagens da fila do Amazon SQS assim que elas se tornam disponíveis.
+ Para reduzir o custo do uso do Amazon SQS e diminuir o número de recebimentos vazios em uma fila vazia (respostas à ação `ReceiveMessage` que não retornam nenhuma mensagem), habilite a sondagem longa. Para obter mais informações, consulte [Sondagem longa do Amazon SQS](sqs-short-and-long-polling.md).
+ Para aumentar a eficiência ao sondar vários threads com vários recebimentos, diminua o número de threads.
+ A sondagem longa é melhor do que a sondagem curta na maioria dos casos.
+ A sondagem curta retorna respostas imediatamente, mesmo que a fila do Amazon SQS sondada esteja vazia.
+ Para satisfazer os requisitos de um aplicativo que espera respostas imediatas para a solicitação `ReceiveMessage`, use a sondagem curta.
+ A sondagem curta é cobrada pelo mesmo custo de uma sondagem longa.