Menu
Amazon Simple Queue Service
Developer Guide

General Recommendations

The following guidelines can help you reduce costs and process messages efficiently using Amazon SQS.

Processing Messages

  • To ensure that there is sufficient time to process a message, you should use one of the following strategies:

    • If you know (or can reasonably estimate) how long it takes to process a message, extend the message's visibility timeout to the maximum time it takes to process and delete the message. For more information, see Configuring the Visibility Timeout and Changing a Message's Visibility Timeout.

    • If you don't know how long it takes to process a message, specify the initial visibility timeout (for example, 2 minutes) and the period of time after which you can check whether the message is processed (for example, 1 minute). If the message isn't processed, extend the visibility timeout (for example, to 3 minutes).

    Note

    If you need to extend the visibility timeout for longer than 12 hours, consider using AWS Step Functions.

  • To handle request errors, you should use one of the following strategies:

    • If you use an AWS SDK, you already have automatic retry and backoff logic at your disposal. For more information, see Error Retries and Exponential Backoff in AWS in the Amazon Web Services General Reference.

    • If you do not use the AWS SDK features for retry and backoff, allow a pause (for example, 200 ms) before retrying the ReceiveMessage action after receiving no messages, a timeout, or an error message from Amazon SQS. For subsequent use of ReceiveMessage that gives the same results, allow a longer pause (for example, 400 ms).

  • To capture all messages that can't be processed, and to ensure the correctness of CloudWatch metrics, you should configure a dead-letter queue.

    • The redrive policy redirects messages to a dead-letter queue after the source queue fails to process a message a specified number of times.

    • Using a dead-letter queue decreases the number of messages and reduces the possibility of exposing you to poison pill messages (messages that are received but can't be processed).

    • Including a poison pill message in a queue can distort the ApproximateAgeOfOldestMessage CloudWatch metric by giving an incorrect age of the poison pill message. Configuring a dead-letter queue helps avoid false alarms when using this metric.

  • To avoid inconsistent message processing by standard queues, avoid setting the number of maximum receives to 1 when you configure a dead-letter queue.

    Important

    In some unlikely scenarios, if you set the number of maximum receives to 1, any time a ReceiveMessage call fails, a message might be moved to a dead-letter queue without being received.

Reducing Costs

  • To reduce costs, batch your message actions:

    • To send, receive, and delete messages, and to change the message visibility timeout for multiple messages with a single action, use the Amazon SQS batch API actions.

    • To combine client-side buffering with request batching, use long polling together with the buffered asynchronous client included with the AWS SDK for Java.

      Note

      The Amazon SQS Buffered Asynchronous Client doesn't currently support FIFO queues.

  • To take advantage of additional potential reduced cost or near-instantaneous response, use one of the following polling modes:

    • Long polling lets you consume messages from your Amazon SQS queue as soon as they become available.

      • To reduce the cost of using Amazon SQS and to decrease the number of empty receives to an empty queue (responses to the ReceiveMessage action which return no messages), enable long polling. For more information, see Amazon SQS Long Polling.

      • To increase efficiency when polling for multiple threads with multiple receives, decrease the number of threads.

      • Long polling is preferable over short polling in most cases.

    • Short polling returns responses immediately, even if the polled Amazon SQS queue is empty.

      • To satisfy the requirements of an application that expects immediate responses to the ReceiveMessage request, use short polling.

      • Short polling is billed the same as long polling.

Moving from a Standard Queue to a FIFO Queue

  • If you're not setting the DelaySeconds parameter on each message, you can move to a FIFO queue by providing a message group ID for every sent message. For more information, see Moving from a Standard Queue to a FIFO Queue.