Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Prácticas recomendadas para Amazon SQS
Amazon SQS administra y procesa las colas de mensajes, lo que permite que las distintas partes de una aplicación intercambien mensajes de forma fiable y a escala. En esta tema se describen las principales prácticas recomendadas operativas, como el uso de sondeos largos para reducir las respuestas vacías, la implementación de colas de mensajes fallidos para gestionar los errores de procesamiento y la optimización de los permisos de las colas por motivos de seguridad.
****Temas****
+ [Gestión de errores y mensajes problemáticos](best-practices-error-handling.md)
+ [Desduplicación y agrupación de mensajes](best-practices-message-deduplication.md)
+ [Procesamiento y temporización de mensajes](best-practices-message-processing.md)
# Gestión de errores y mensajes problemáticos en Amazon SQS
Este tema proporciona instrucciones detalladas sobre la gestión y la mitigación de errores en Amazon SQS, incluidas las técnicas para administrar los errores de las solicitudes, capturar los mensajes problemáticos y configurar la retención de colas de mensajes fallidos para garantizar la fiabilidad de los mensajes.
****Temas****
+ [Gestión de errores de solicitudes en Amazon SQS](handling-request-errors.md)
+ [Captura de mensajes problemáticos en Amazon SQS](capturing-problematic-messages.md)
+ [Configuración de la retención de la cola de mensajes fallidos en Amazon SQS](setting-up-dead-letter-queue-retention.md)
# Gestión de errores de solicitudes en Amazon SQS
Para gestionar los errores de solicitud, utilice una de las siguientes estrategias:
+ Si utilizas un AWS SDK, ya tienes a tu disposición una lógica automática de *reintentos y retrocesos*. Para obtener más información, consulte [Reintentos de error y retroceso exponencial en AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) en la *Referencia general de Amazon Web Services*.
+ Si no utiliza las funciones del AWS SDK para volver a intentarlo y retrasar, espere una pausa (por ejemplo, 200 ms) antes de volver a intentar la [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)acción si no recibe ningún mensaje, si se agota el tiempo de espera o si recibe un mensaje de error de Amazon SQS. Si quiere utilizar posteriormente `ReceiveMessage` con los mismos resultados, haga una pausa mayor (por ejemplo, 400 ms).
# Captura de mensajes problemáticos en Amazon SQS
Para capturar todos los mensajes que no se pueden procesar y recopilar CloudWatch métricas precisas, configura una cola de mensajes [sin procesar.](sqs-dead-letter-queues.md)
+ La política de redireccionamiento redirige los mensajes a una cola de mensajes fallidos después de que la cola de origen no puede procesar un mensaje un número especificado de veces.
+ El uso de una cola de mensajes fallidos reduce el número de mensajes y la posibilidad de exponer el sistema a mensajes de *píldoras venenosas* (mensajes que se reciben pero no se pueden procesar).
+ Incluir un mensaje sobre una píldora venenosa en una lista puede distorsionar la [`ApproximateAgeOfOldestMessage`](sqs-available-cloudwatch-metrics.md) CloudWatch métrica al indicar una antigüedad incorrecta del mensaje sobre la píldora venenosa. Cuando se utiliza esta métrica, la configuración de una cola de mensajes fallidos ayuda a evitar falsas alarmas.
# Configuración de la retención de la cola de mensajes fallidos en Amazon SQS
En el caso de las colas estándar, la caducidad de un mensaje siempre se basa en su marca temporal original. Cuando un mensaje se mueve a una cola de mensajes fallidos, la marca temporal de la cola no se modifica. La métrica `ApproximateAgeOfOldestMessage` indica cuándo el mensaje pasó a la cola de mensajes fallidos, *no* cuándo se envió originalmente. Por ejemplo, supongamos que un mensaje pasa un día en la cola original antes de ser trasladado a una cola de mensajes fallidos. Si el periodo de retención de la cola de mensajes fallidos es de cuatro días, el mensaje se elimina de la cola de mensajes fallidos al cabo de tres días y `ApproximateAgeOfOldestMessage` es de tres días. Por lo tanto, se recomienda establecer siempre un periodo de retención de una cola de mensajes fallidos superior al periodo de retención de la cola original.
Para las colas FIFO, la marca temporal de entrada se restablece cuando el mensaje se mueve a una cola de mensajes fallidos. La métrica `ApproximateAgeOfOldestMessage` indica cuándo el mensaje ha pasado a la cola de mensajes fallidos. En el mismo ejemplo anterior, el mensaje se elimina de la cola de mensajes fallidos al cabo de cuatro días y `ApproximateAgeOfOldestMessage` es de cuatro días.
# Desduplicación y agrupación de mensajes de Amazon SQS
En este tema se describen las prácticas recomendadas para garantizar un procesamiento coherente de los mensajes en Amazon SQS. En él, se explica cómo utilizar:
+ [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 mensajes duplicados en las colas FIFO.
+ [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) para administrar el orden de los mensajes dentro de grupos de mensajes distintos.
****Temas****
+ [Cómo evitar el procesamiento incoherente de los mensajes en Amazon SQS](avoiding-inconsistent-message-processing.md)
+ [Uso del ID de desduplicación de mensajes](using-messagededuplicationid-property.md)
+ [Uso del ID de grupo de mensajes](using-messagegroupid-property.md)
+ [Uso del ID de intento de solicitud de recepción](using-receiverequestattemptid-request-parameter.md)
# Cómo evitar el procesamiento incoherente de los mensajes en Amazon SQS
Debido a que Amazon SQS es un sistema distribuido, es posible que un consumidor no reciba un mensaje aunque Amazon SQS lo marque como entregado al regresar correctamente de una llamada de método de API [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html). En este caso, Amazon SQS registra el mensaje como entregado al menos una vez, aunque el consumidor no lo haya recibido. Dado que no se realizan intentos adicionales de entregar mensajes en estas condiciones, no recomendamos establecer el número máximo de recepciones en 1 para una [cola de mensajes fallidos](sqs-dead-letter-queues.md).
# Uso del ID de desduplicación de mensajes en Amazon SQS
[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) es un token que se utiliza únicamente en las colas FIFO de Amazon SQS para evitar la entrega de mensajes duplicados. Garantiza que, en un intervalo de desduplicación de 5 minutos, solo se procese y entregue una instancia de un mensaje con el mismo ID de desduplicación.
Si Amazon SQS ya ha aceptado un mensaje con un ID de desduplicación específico, se confirmará cualquier mensaje posterior con el mismo ID, pero no se entregará a los consumidores.
**nota**
Amazon SQS sigue realizando un seguimiento del ID de desduplicación incluso después de que el mensaje se haya recibido y eliminado.
**Topics**
+ [Cuándo proporcionar un ID de desduplicación de mensajes en Amazon SQS](providing-message-deduplication-id.md)
+ [Habilitación de la desduplicación para un sistema de un solo productor y un solo consumidor en Amazon SQS](single-producer-single-consumer.md)
+ [Escenarios de recuperación de interrupciones en Amazon SQS](designing-for-outage-recovery-scenarios.md)
+ [Configuración de tiempos de espera de visibilidad en Amazon SQS](working-with-visibility-timeouts.md)
# Cuándo proporcionar un ID de desduplicación de mensajes en Amazon SQS
Un productor debe especificar un ID de desduplicación de mensajes en los siguientes escenarios:
+ Al enviar cuerpos de mensajes idénticos que deben tratarse como únicos.
+ Al enviar mensajes con el mismo contenido pero con atributos de mensaje diferentes, lo que garantiza que cada mensaje se procese por separado.
+ Al enviar mensajes con contenido diferente (por ejemplo, un contador de reintentos incluido en el cuerpo del mensaje) pero que requieren que Amazon SQS los reconozca como duplicados.
# Habilitación de la desduplicación para un sistema de un solo productor y un solo consumidor en Amazon SQS
Si tiene un único productor y un único consumidor y los mensajes son exclusivos porque incluyen un ID de mensaje específico de la aplicación en el cuerpo, siga estas prácticas recomendadas:
+ Habilite la desduplicación basada en el contenido para la cola (cada uno de sus mensajes tiene un cuerpo único). El productor puede omitir el ID de desduplicación de mensajes.
+ Cuando la desduplicación basada en contenido está habilitada para una cola FIFO de Amazon SQS y se envía un mensaje con un ID de desduplicación, el ID de desduplicación [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) invalida el ID de desduplicación basado en contenido generado.
+ Aunque no es necesario que el consumidor proporcione un ID de intento de solicitud de recepción para cada solicitud, es recomendable hacerlo porque permite que las secuencias de reintento tras un error se ejecuten con mayor rapidez.
+ Puede reintentar las solicitudes de envío o recepción, ya que no interfieren con la ordenación de los mensajes en las colas FIFO.
# Escenarios de recuperación de interrupciones en Amazon SQS
El proceso de desduplicación en las colas FIFO está sujeto a limitación temporal. Al diseñar una aplicación, asegúrese de que tanto el productor como el consumidor puedan recuperarse de las interrupciones del cliente o de la red sin introducir duplicados o errores de procesamiento.
Consideraciones sobre el productor
+ Amazon SQS aplica un intervalo de desduplicación de 5 minutos.
+ Si un productor vuelve a intentar una solicitud [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) transcurridos 5 minutos, Amazon SQS la considera como un mensaje nuevo, lo que podría crear duplicados.
Consideraciones sobre el consumidor
+ Si un consumidor no procesa un mensaje antes de que se agote el tiempo de espera de visibilidad, puede que otro consumidor lo reciba y procese, lo que daría lugar a una duplicación del procesamiento.
+ Ajuste el tiempo de espera de visibilidad en función del tiempo de procesamiento de la aplicación.
+ Use la API [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html) para ampliar el tiempo de espera mientras se procesa un mensaje.
+ Si un mensaje no se puede procesar repetidamente, diríjalo a una [cola de mensajes fallidos (DLQ)](sqs-dead-letter-queues.md) en lugar de permitir que se vuelva a procesar por tiempo indefinido.
+ El productor debe estar al tanto del intervalo de desduplicación de la cola. Amazon SQS tiene un intervalo mínimo de desduplicación de cinco minutos. El reintento de solicitudes `SendMessage` después de que finalice el intervalo de desduplicación puede introducir mensajes duplicados en la cola. Por ejemplo, un dispositivo móvil en un automóvil envía mensajes cuyo orden es importante. Si el automóvil pierde la conectividad móvil durante un periodo de tiempo antes de recibir un reconocimiento, el reintento de la solicitud después de recuperar la conectividad móvil puede crear un duplicado.
+ El consumidor debe tener un tiempo de espera de visibilidad que minimice el riesgo de no poder procesar los mensajes antes de que finalice el tiempo de espera de visibilidad. Para ampliar el tiempo de espera de visibilidad mientras se procesan los mensajes, llame a la acción `ChangeMessageVisibility`. Sin embargo, si el tiempo de espera de visibilidad finaliza, otro consumidor puede comenzar inmediatamente a procesar los mensajes, lo que hará que un mensaje se procese varias veces. Para evitar esta situación, configure una [cola de mensajes fallidos](sqs-dead-letter-queues.md).
# Configuración de tiempos de espera de visibilidad en Amazon SQS
Para garantizar un procesamiento fiable de los mensajes, establece el tiempo de espera de visibilidad para que sea superior al tiempo de espera de lectura del AWS SDK. Esto se aplica cuando se utiliza la API [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html) tanto con sondeos cortos como con sondeos largos. Un tiempo de espera de visibilidad más largo evita que los mensajes estén disponibles para los demás consumidores antes de que se complete la solicitud original, lo que reduce el riesgo de que se duplique el procesamiento.
# Uso del ID de grupo de mensajes con las colas FIFO de Amazon SQS
En las colas FIFO (primero en entrar, primero en salir), [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) es un atributo que organiza los mensajes en grupos distintos. Los mensajes de un mismo grupo siempre se procesan de uno en uno, siguiendo un orden estricto, lo que garantiza que no se procesen dos mensajes del mismo grupo simultáneamente. En las colas estándar, el uso de `MessageGroupId` permite crear [colas justas](sqs-fair-queues.md). Si se requiere un orden estricto, utilice una cola FIFO.
**Topics**
+ [Intercalación de varios grupos de mensajes ordenados en Amazon SQS](interleaving-multiple-ordered-message-groups.md)
+ [Prevención del procesamiento duplicado en un sistema de varios productores y consumidores en Amazon SQS](avoding-processing-duplicates-in-multiple-producer-consumer-system.md)
+ [Elusión del volumen de tareas pendientes de mensajes con el mismo ID de grupo de mensajes en Amazon SQS](avoid-backlog-with-the-same-message-group-id.md)
+ [Cómo evitar reutilizar el mismo ID de grupo de mensajes con colas virtuales en Amazon SQS](avoiding-reusing-message-group-id-with-virtual-queues.md)
# Intercalación de varios grupos de mensajes ordenados en Amazon SQS
Para intercalar varios grupos de mensajes ordenados dentro de una única cola FIFO, asigne un [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) a cada grupo (por ejemplo, datos de sesiones para diferentes usuarios). Esto permite que varios consumidores lean de la cola simultáneamente, al tiempo que se garantiza que los mensajes del mismo grupo se procesen en orden.
Cuando se está procesando un mensaje con un `MessageGroupId` específico y este es invisible, ningún otro consumidor puede procesar mensajes de ese mismo grupo hasta que se agote el tiempo de espera de visibilidad o se elimine el mensaje.
# Prevención del procesamiento duplicado en un sistema de varios productores y consumidores en Amazon SQS
En un sistema de alto rendimiento y baja latencia en el que el orden de los mensajes no es una prioridad, los productores pueden asignar un [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) único a cada mensaje. Esto garantiza que las colas FIFO de Amazon SQS eliminen los duplicados, incluso en una configuración con varios productores y varios consumidores. Si bien este enfoque evita la duplicación de mensajes, no garantiza el orden de los mismos, ya que cada mensaje se trata como un grupo independiente.
En cualquier sistema con varios productores y consumidores, siempre existe el riesgo de que se produzcan duplicados en la entrega. Si un consumidor no procesa un mensaje antes de que expire el tiempo de espera de visibilidad, Amazon SQS vuelve a hacer que el mensaje esté disponible, lo que posiblemente permita que otro consumidor lo recoja. Para mitigar esta situación, asegúrese de configurar correctamente la confirmación de mensajes y el tiempo de espera de visibilidad en función del tiempo de procesamiento.
# Elusión del volumen de tareas pendientes de mensajes con el mismo ID de grupo de mensajes en Amazon SQS
Las colas FIFO admiten un máximo de 120 000 mensajes en tránsito (mensajes recibidos por un consumidor, pero que aún no se han eliminado). Si se alcanza este límite, Amazon SQS no devuelve ningún error, pero el procesamiento puede verse afectado. Puede solicitar un aumento por encima de este límite poniéndose en contacto con [AWS Support](https://docs.aws.amazon.com/awssupport/latest/user/create-service-quota-increase.html).
Las colas FIFO escanean los primeros 120 000 mensajes para determinar los grupos de mensajes disponibles. Si se acumula un gran volumen de tareas pendientes en un solo grupo de mensajes, los mensajes de los demás grupos enviados posteriormente permanecerán bloqueados hasta que se procesen las tareas pendientes.
**nota**
Puede haber tareas pendientes de mensajes cuando un consumidor no logra procesar un mensaje repetidamente. Esto puede deberse a problemas con el contenido de los mensajes o a errores por parte del consumidor. Para evitar retrasos en el procesamiento de los mensajes, configure una [cola de mensajes fallidos](sqs-dead-letter-queues.md) para trasladar los mensajes no procesados después de varios intentos fallidos. De este modo, se garantiza que los demás mensajes del mismo grupo puedan procesarse, lo que evita los cuellos de botella en el sistema.
# Cómo evitar reutilizar el mismo ID de grupo de mensajes con colas virtuales en Amazon SQS
Cuando utilice colas virtuales con una cola de host compartida, evite reutilizar el mismo [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) en distintas colas virtuales. Si varias colas virtuales comparten la misma cola de host y contienen mensajes con el mismo `MessageGroupId`, esos mensajes pueden bloquearse entre sí, lo que impide un procesamiento eficiente. Para garantizar un procesamiento fluido de los mensajes, asigne valores `MessageGroupId` únicos a los mensajes de las diferentes colas virtuales.
# Uso del ID de intento de solicitud de recepción de Amazon SQS
El ID de intento de solicitud de recepción es un token único que se utiliza para desduplicar las llamadas a [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html) en Amazon SQS. Durante una interrupción de la red o un problema de conectividad entre la aplicación y Amazon SQS, se recomienda lo siguiente:
+ Proporcione un ID de intento de solicitud de recepción al realizar una llamada a `ReceiveMessage`.
+ Vuelva a intentarlo con el mismo ID de intento de solicitud de recepción si la operación falla.
# Procesamiento y temporización de mensajes de Amazon SQS
En este tema se proporciona una guía completa sobre cómo optimizar la velocidad y la eficiencia de la gestión de mensajes en Amazon SQS, incluidas las estrategias para el procesamiento puntual de los mensajes, la selección del mejor modo de sondeo y la configuración del sondeo largo para mejorar el rendimiento.
****Temas****
+ [Procesamiento de los mensajes a tiempo en Amazon SQS](best-practices-processing-messages-timely-manner.md)
+ [Configuración del sondeo largo en Amazon SQS](best-practices-setting-up-long-polling.md)
+ [Uso del modo de sondeo apropiado en Amazon SQS](best-practices-using-appropriate-polling-mode.md)
# Procesamiento de los mensajes a tiempo en Amazon SQS
La configuración del tiempo de espera de visibilidad depende de lo que tarde la aplicación en procesar y eliminar un mensaje. Por ejemplo, si la aplicación necesita 10 segundos para procesar un mensaje y establece el tiempo de espera de visibilidad en 15 minutos, debe esperar un tiempo relativamente largo para intentar procesar el mensaje de nuevo si el intento de procesamiento anterior produce un error. Asimismo, si la aplicación requiere 10 segundos para procesar un mensaje pero el usuario establece el tiempo de espera de visibilidad en solo 2 segundos, otro consumidor recibe un mensaje duplicado mientras que el consumidor original sigue trabajando en el mensaje.
Para asegurarse de que hay tiempo suficiente para procesar los mensajes, utilice una de las siguientes estrategias:
+ Si sabe (o puede calcular razonablemente) el tiempo que se tarda en procesar un mensaje, amplíe el *tiempo de espera de visibilidad* del mensaje al tiempo máximo que se tarda en procesar y eliminar el mensaje. Para obtener más información, consulte [Configuración del tiempo de espera de visibilidad](sqs-visibility-timeout.md#configuring-visibility-timeout).
+ Si no sabe cuánto tiempo tarda en procesarse un mensaje, cree un *latido* para su proceso consumidor: especifique el tiempo de espera de visibilidad inicial (por ejemplo, dos minutos) y, a continuación, mientras su consumidor siga trabajando en el mensaje, continúe ampliando el tiempo de espera de visibilidad en dos minutos cada minuto.
**importante**
El tiempo máximo de visibilidad es de 12 horas desde el momento en que Amazon SQS recibe la solicitud `ReceiveMessage`. La ampliación del tiempo de espera de visibilidad no restablece el máximo de 12 horas.
Además, es posible que no pueda establecer el tiempo de espera de un mensaje individual en 12 horas completas (por ejemplo, 43 200 segundos), ya que la solicitud `ReceiveMessage` inicia el temporizador. Por ejemplo, si recibe un mensaje e inmediatamente establece el máximo de 12 horas mediante el envío de una llamada `ChangeMessageVisibility` con `VisibilityTimeout` igual a 43 200 segundos, es probable que se produzca un error. No obstante, utilizar un valor de 43 195 segundos funcionará a menos que exista un retraso significativo entre la solicitud del mensaje a través de `ReceiveMessage` y la actualización del tiempo de espera de visibilidad. Si su consumidor necesita más de 12 horas, considere usar Step Functions.
# Configuración del sondeo largo en Amazon SQS
Cuando el tiempo de espera de la acción de la API `[ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)` es superior a 0, se está realizando un *sondeo largo*. El tiempo máximo de espera de sondeo es de 20 segundos. Las encuestas prolongadas ayudan a reducir el costo de usar Amazon SQS al reducir el número de respuestas vacías (cuando no hay mensajes disponibles para una `ReceiveMessage` solicitud) y de respuestas falsas vacías (cuando hay mensajes disponibles pero no se incluyen en una respuesta). Para obtener más información, consulte [Sondeos cortos y largos de Amazon SQS](sqs-short-and-long-polling.md).
Para obtener un procesamiento óptimo de los mensajes, utilice las siguientes estrategias:
+ En la mayoría de los casos, puede establecer el tiempo de espera de `ReceiveMessage` en 20 segundos. Si 20 segundos es demasiado tiempo para su aplicación, establezca un tiempo de espera de `ReceiveMessage` más corto (1 segundo como mínimo). Si no utiliza un AWS SDK para acceder a Amazon SQS o si configura un AWS SDK para que tenga un tiempo de espera más corto, es posible que tenga que modificar su cliente de Amazon SQS para permitir solicitudes más largas o utilizar un tiempo de espera más corto para sondeos prolongados.
+ Si implementa el sondeo largo para varias colas, utilice un subproceso para cada cola en lugar de un solo subproceso para todas las colas. El uso de un único subproceso para cada cola permite que la aplicación procese los mensajes de cada una de las colas en cuanto estén disponibles, mientras que el uso de un único subproceso para sondear varias colas podría impedir que su aplicación procesara los mensajes disponibles en otras colas mientras la aplicación espera (hasta 20 segundos) para la cola que no tiene ningún mensaje disponible.
**importante**
Para evitar errores HTTP, asegúrese de que el tiempo de espera de respuesta HTTP de las solicitudes `ReceiveMessage` sea mayor que el parámetro `WaitTimeSeconds`. Para obtener más información, consulte [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html).
# Uso del modo de sondeo apropiado en Amazon SQS
+ El sondeo largo le permite consumir mensajes de la cola de Amazon SQS tan pronto como estén disponibles.
+ Para reducir el costo derivado del uso de Amazon SQS y reducir el número de recepciones vacías en una cola vacía (respuestas a la acción `ReceiveMessage` que no devuelven ningún mensaje), habilite el sondeo largo. Para obtener más información, consulte [Sondeo largo de Amazon SQS](sqs-short-and-long-polling.md).
+ Para aumentar la eficacia cuando se sondean varios subprocesos con varias recepciones, reduzca el número de procesos.
+ En la mayoría de los casos, el sondeo largo es preferible al sondeo corto.
+ El sondeo corto devuelve respuestas inmediatamente, incluso aunque la cola de Amazon SQS sondeada esté vacía.
+ Para satisfacer los requisitos de una aplicación que espera respuestas inmediatas a la solicitud `ReceiveMessage`, utilice el sondeo corto.
+ El sondeo corto se factura igual que el sondeo largo.