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á.
# Práticas recomendadas do Amazon SQS
O Amazon SQS gerencia e processa filas de mensagens, permitindo que diferentes partes de uma aplicação troquem mensagens de forma confiável e escalável. Este tópico aborda as práticas recomendadas operacionais essenciais, incluindo o uso de sondagens longas a fim de reduzir respostas vazias, a implementação de filas de mensagens não entregues para gerenciar erros de processamento e a otimização de permissões de fila para fins de segurança.
****Tópicos****
+ [Gerenciamento de erros e mensagens problemáticas](best-practices-error-handling.md)
+ [Desduplicação e agrupamento de mensagens](best-practices-message-deduplication.md)
+ [Tempo e processamento de mensagens](best-practices-message-processing.md)
# Gerenciamento de erros e mensagens problemáticas do Amazon SQS
Este tópico fornece instruções detalhadas sobre como gerenciar e mitigar erros no Amazon SQS, incluindo técnicas para lidar com erros de solicitação, capturar mensagens problemáticas e configurar a retenção da fila de mensagens não entregues para garantir a confiabilidade das mensagens.
****Tópicos****
+ [Gerenciamento de erros de solicitação no Amazon SQS](handling-request-errors.md)
+ [Capturar mensagens problemáticas no Amazon SQS](capturing-problematic-messages.md)
+ [Configurar a retenção da fila de mensagens não entregues no Amazon SQS](setting-up-dead-letter-queue-retention.md)
# Gerenciamento de erros de solicitação no Amazon SQS
Para gerenciar erros de solicitação, use uma das seguintes estratégias:
+ Se você usa um AWS SDK, já tem uma lógica automática de *repetição e recuo* à sua disposição. Para ter mais informações, consulte [Repetições de erro e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) no *Referência geral da Amazon Web Services*.
+ Se você não usa os recursos do AWS SDK para tentar novamente e recuar, faça uma pausa (por exemplo, 200 ms) antes de tentar novamente a [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)ação depois de não receber nenhuma mensagem, um tempo limite ou uma mensagem de erro do Amazon SQS. Para o uso subsequente de `ReceiveMessage` que oferece os mesmos resultados, faça uma pausa maior (por exemplo, 400 ms).
# Capturar mensagens problemáticas no Amazon SQS
Para capturar todas as mensagens que não podem ser processadas e coletar CloudWatch métricas precisas, configure uma fila de mensagens [mortas.](sqs-dead-letter-queues.md)
+ A política de redirecionamento redireciona mensagens para uma dead letter queue depois que a fila de origem falha em processar uma mensagem um número de vezes especificado.
+ O uso da dead letter queue diminui o número de mensagens e reduz a possibilidade de exposição a mensagens *poison pill* (mensagens que podem ser recebidas, mas que não podem ser processadas).
+ Incluir uma mensagem de pílula venenosa em uma fila pode distorcer a [`ApproximateAgeOfOldestMessage`](sqs-available-cloudwatch-metrics.md) CloudWatch métrica, fornecendo uma idade incorreta da mensagem da pílula venenosa. Configurar uma dead letter queue ajuda a evitar alarmes falsos ao usar essa métrica.
# Configurar a retenção da fila de mensagens não entregues no Amazon SQS
Para filas comuns, a validade de uma mensagem é sempre baseada em seu carimbo de data/hora de enfileiramento original. Quando uma mensagem é movida para uma fila de mensagens mortas, o carimbo de data/hora de enfileiramento permanece inalterado. A métrica `ApproximateAgeOfOldestMessage` indica quando a mensagem foi movida para a fila de mensagens não entregues, *não* quando a mensagem foi originalmente enviada. Por exemplo, suponha que uma mensagem fique um dia na fila original antes de ser movida para uma fila de mensagens mortas. Se o período de retenção da fila de mensagens mortas for de quatro dias, a mensagem será excluída da fila de mensagens mortas após três dias e a `ApproximateAgeOfOldestMessage` será de três dias. Portanto, é uma prática recomendada definir sempre o período de retenção de uma fila de mensagens mortas para ser maior do que o período de retenção da fila original.
Para filas FIFO, o carimbo de data/hora da fila é redefinido quando a mensagem é movida para uma fila de mensagens não entregues. A métrica `ApproximateAgeOfOldestMessage` indica quando a mensagem foi movida para a fila de mensagens não entregues. No mesmo exemplo acima, a mensagem é excluída da fila de mensagens não entregues após quatro dias e `ApproximateAgeOfOldestMessage` é de quatro dias.
# Desduplicação e agrupamento de mensagens do Amazon SQS
Este tópico fornece as práticas recomendadas para garantir o processamento consistente de mensagens no Amazon SQS. Aqui, você encontrará explicações para como usar:
+ [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html#API_SendMessage_RequestSyntax](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html#API_SendMessage_RequestSyntax) para evitar mensagens duplicadas nas filas FIFO.
+ [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) para gerenciar a ordenação de mensagens em grupos de mensagens distintos.
****Tópicos****
+ [Evitar o processamento inconsistente de mensagens no Amazon SQS](avoiding-inconsistent-message-processing.md)
+ [Uso do ID de eliminação de duplicação de mensagens](using-messagededuplicationid-property.md)
+ [Uso do ID do grupo de mensagens](using-messagegroupid-property.md)
+ [Uso do ID de tentativa de solicitação de recebimento](using-receiverequestattemptid-request-parameter.md)
# Evitar o processamento inconsistente de mensagens no Amazon SQS
Como o Amazon SQS é um sistema distribuído, é possível que um consumidor não receba uma mensagem mesmo quando o Amazon SQS a marcar como entregue ao retornar com êxito de uma chamada de método da API [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html). Nesse caso, o Amazon SQS registra a mensagem como entregue pelo menos uma vez, embora o consumidor nunca a tenha recebido. Como nenhuma tentativa adicional de entregar mensagens é feita sob essas condições, não recomendamos definir o número máximo de recebimentos como 1 para uma [fila de mensagens mortas](sqs-dead-letter-queues.md).
# Usar o ID de desduplicação de mensagens do Amazon SQS
[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) é um token usado apenas em filas FIFO do Amazon SQS para evitar a entrega duplicada de mensagens. Ele garante que, dentro de um intervalo de desduplicação de cinco minutos, somente uma instância de uma mensagem com o mesmo ID de desduplicação seja processada e entregue.
Se o Amazon SQS já aceitou uma mensagem com um ID específico de desduplicação, todas as mensagens subsequentes com o mesmo ID serão reconhecidas, mas não serão entregues aos consumidores.
**nota**
O Amazon SQS continua acompanhando o ID de desduplicação da mensagem mesmo depois que a mensagem é recebida e excluída.
**Topics**
+ [Quando fornecer o ID de desduplicação de mensagens no Amazon SQS](providing-message-deduplication-id.md)
+ [Habilitar a desduplicação para um sistema de produtor/consumidor único no Amazon SQS](single-producer-single-consumer.md)
+ [Cenários de recuperação de interrupção no Amazon SQS](designing-for-outage-recovery-scenarios.md)
+ [Como configurar tempo limite de visibilidade no Amazon SQS](working-with-visibility-timeouts.md)
# Quando fornecer o ID de desduplicação de mensagens no Amazon SQS
O produtor deve especificar um ID de desduplicação de mensagens nos seguintes cenários:
+ Ao enviar corpos de mensagens idênticos que devem ser tratados como exclusivos.
+ Ao enviar mensagens com o mesmo conteúdo, mas com atributos de mensagem diferentes, garantindo que cada mensagem seja processada separadamente.
+ Ao enviar mensagens com conteúdo diferente (por exemplo, um contador de repetições no corpo da mensagem), mas solicitando que o Amazon SQS as reconheça como duplicações.
# Habilitar a desduplicação para um sistema de produtor/consumidor único no Amazon SQS
Se você tiver um único produtor e um único consumidor, e as mensagens forem exclusivas porque incluem um ID de mensagem específico da aplicação incluído no corpo, siga as práticas recomendadas a seguir:
+ Ative a eliminação de duplicação baseada em conteúdo para a fila (cada uma de suas mensagens tem um único corpo). O produtor pode omitir o ID de eliminação de duplicação de mensagem.
+ Quando a desduplicação baseada em conteúdo é habilitada para uma fila FIFO do Amazon SQS e uma mensagem é enviada com um ID de desduplicação, o ID de desduplicação [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) substitui o ID de desduplicação baseado no conteúdo gerado.
+ Embora o consumidor não seja obrigado a fornecer um ID de tentativa de solicitação de recebimento, isso é uma prática recomendada porque permite que sequências de tentativa de recuperação de falhas sejam executadas mais rapidamente.
+ Você pode tentar enviar ou receber solicitações novamente, porque elas não interferem na ordenação de mensagens em filas FIFO.
# Cenários de recuperação de interrupção no Amazon SQS
O processo de eliminação de duplicação em filas FIFO é depende do tempo. Ao projetar sua aplicação, garanta que o produtor e o consumidor possam se recuperar de interrupções de cliente ou da rede sem introduzir duplicações ou falhas de processamento.
Considerações sobre o produtor
+ O Amazon SQS impõe uma janela de desduplicação de cinco minutos.
+ Se um produtor tentar novamente uma solicitação [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) após cinco minutos, o Amazon SQS a tratará como uma nova mensagem, potencialmente criando duplicatas.
Considerações sobre o consumidor
+ Se o consumidor não processar uma mensagem antes que o tempo limite de visibilidade expire, outro consumidor poderá recebê-la e processá-la, resultando em um processamento duplicado.
+ Ajuste o tempo limite de visibilidade com base no tempo de processamento da sua aplicação.
+ Use a API [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html) para estender o tempo limite enquanto uma mensagem ainda está sendo processada.
+ Se uma mensagem falhar repetidamente no processamento, encaminhe-a para uma [fila de mensagens não entregues (DLQ)](sqs-dead-letter-queues.md) em vez de permitir que ela seja reprocessada indefinidamente.
+ O produtor deve estar ciente do intervalo de eliminação de duplicação da fila. O Amazon SQS tem um intervalo de eliminação de duplicação de cinco minutos. Repetir solicitações `SendMessage` após a expiração do intervalo da eliminação de duplicação pode introduzir mensagens duplicadas na fila. Por exemplo, um dispositivo móvel em um carro envia mensagens cuja ordem é importante. Se o carro perder a conectividade celular por um período antes de receber uma confirmação, tentar novamente a solicitação depois de recuperada a conectividade celular pode criar uma duplicação.
+ O consumidor deve ter um tempo limite de visibilidade que minimize o risco de não conseguir processar as mensagens antes que o tempo limite de visibilidade expire. Você pode estender o tempo limite de visibilidade enquanto as mensagens estão sendo processadas chamando a ação `ChangeMessageVisibility`. No entanto, se o tempo limite de visibilidade expirar, outro consumidor poderá começar imediatamente a processar as mensagens, fazendo com que uma mensagem seja processada várias vezes. Para evitar essa situação, configure uma [dead letter queue](sqs-dead-letter-queues.md).
# Como configurar tempo limite de visibilidade no Amazon SQS
Para garantir um processamento confiável de mensagens, defina o tempo limite de visibilidade para ser maior que o tempo limite de leitura do AWS SDK. Isso se aplica ao usar a ação de API [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html) com sondagem curta e sondagem longa. Um tempo limite de visibilidade maior impede que as mensagens sejam disponibilizadas para outros consumidores antes que a solicitação original seja concluída, reduzindo o risco de processamento duplicado.
# Usar o ID do grupo de mensagens com filas FIFO do Amazon SQS
Em filas FIFO (First-In First-Out — primeira a entrar, primeira a sair), [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) é um atributo que organiza mensagens em grupos distintos. As mensagens dentro do mesmo grupo são sempre processadas uma por vez, em ordem estrita, garantindo que duas mensagens do mesmo grupo não sejam processadas simultaneamente. Em filas padrão, o uso de `MessageGroupId` ativa [filas justas](sqs-fair-queues.md). Se for necessária uma ordenação estrita, use uma fila FIFO.
**Topics**
+ [Intercalar vários grupos de mensagens ordenadas no Amazon SQS](interleaving-multiple-ordered-message-groups.md)
+ [Como evitar o processamento de duplicatas em um sistema de vários produtores/consumidores no Amazon SQS](avoding-processing-duplicates-in-multiple-producer-consumer-system.md)
+ [Como evitar um grande acúmulo de mensagens com o mesmo ID de grupo de mensagens no Amazon SQS](avoid-backlog-with-the-same-message-group-id.md)
+ [Evitar reutilizar o mesmo ID de grupo de mensagens com filas virtuais no Amazon SQS](avoiding-reusing-message-group-id-with-virtual-queues.md)
# Intercalar vários grupos de mensagens ordenadas no Amazon SQS
Para intercalar vários grupos de mensagens ordenadas em uma única fila FIFO, atribua um [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) para cada grupo (por exemplo, dados de sessão de diferentes usuários). Isso permite que vários consumidores leiam da fila simultaneamente, ao mesmo tempo em que garante que as mensagens dentro do mesmo grupo sejam processadas em ordem.
Quando uma mensagem com um `MessageGroupId` específico estiver sendo processada e ficar invisível, nenhum outro consumidor poderá processar mensagens desse mesmo grupo até que o tempo limite de visibilidade expire ou a mensagem seja excluída.
# Como evitar o processamento de duplicatas em um sistema de vários produtores/consumidores no Amazon SQS
Em um sistema de alto throughput e baixa latência em que a ordenação das mensagens não é uma prioridade, os produtores podem atribuir um [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) exclusivo para cada mensagem. Isso garante que as filas FIFO do Amazon SQS eliminem duplicatas, mesmo em uma configuração de vários produtores/vários consumidores. Embora essa abordagem evite mensagens duplicadas, ela não garante a ordem das mensagens, pois cada mensagem é tratada como seu próprio grupo independente.
Em qualquer sistema com vários produtores e consumidores, sempre existe o risco de entrega duplicada. Se um consumidor não processar uma mensagem antes que o tempo limite de visibilidade expire, o Amazon SQS disponibilizará a mensagem novamente, potencialmente permitindo que outro consumidor a pegue. Para mitigar isso, garanta configurações adequadas de reconhecimento de mensagens e tempo limite de visibilidade com base no tempo de processamento.
# Como evitar um grande acúmulo de mensagens com o mesmo ID de grupo de mensagens no Amazon SQS
As filas FIFO oferecem suporte para um máximo de 120.000 mensagens em trânsito (mensagens recebidas por um consumidor, mas ainda não excluídas). Se esse limite for atingido, o Amazon SQS não retornará um erro, mas o processamento poderá ser afetado. Você pode solicitar um aumento desse limite entrando em contato com o [AWS Support](https://docs.aws.amazon.com/awssupport/latest/user/create-service-quota-increase.html).
Filas FIFO examinam as primeiras 120.000 mensagens para determinar os grupos de mensagens disponíveis. Se houver grande acúmulo em um único grupo de mensagens, as mensagens de outros grupos enviadas posteriormente permanecerão bloqueadas até que o acúmulo seja processado.
**nota**
Um acúmulo de mensagens pode ocorrer quando um consumidor não tem sucesso, repetidamente, no processamento de uma mensagem. Isso pode ser devido a problemas de conteúdo da mensagem ou falhas do lado do consumidor. Para evitar atrasos no processamento de mensagens, configure uma [fila de mensagens não entregues](sqs-dead-letter-queues.md) para mover mensagens não processadas após várias tentativas malsucedidas. Isso garante que outras mensagens no mesmo grupo possam ser processadas, evitando gargalos no sistema.
# Evitar reutilizar o mesmo ID de grupo de mensagens com filas virtuais no Amazon SQS
Ao usar filas virtuais com uma fila de host compartilhado, evite reutilizar o mesmo [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) em diferentes filas virtuais. Se várias filas virtuais compartilharem a mesma fila do host e contiverem mensagens com o mesmo `MessageGroupId`, essas mensagens poderão se bloquear, impedindo o processamento eficiente. Para garantir um processamento sem problemas, atribua valores `MessageGroupId` exclusivos para mensagens em diferentes filas virtuais.
# Usar o ID de tentativa de solicitação de recebimento do Amazon SQS
O ID de tentativa de solicitação de recebimento é um token exclusivo usado para desduplicar chamadas de [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html) no Amazon SQS. Durante uma interrupção na rede ou um problema de conectividade entre sua aplicação e o Amazon SQS, a prática recomendada é:
+ Forneça um ID de tentativa de solicitação de recebimento ao fazer uma chamada de `ReceiveMessage`.
+ Tente novamente usando o mesmo ID de tentativa de solicitação de recebimento se a operação falhar.
# 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.