The following guidelines can help you reduce costs and process messages efficiently using Amazon SQS.
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).
If you need to extend the visibility timeout for longer than 12 hours, consider using Amazon Simple Workflow Service.
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
ReceiveMessagethat 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
ApproximateAgeOfOldestMessageCloudWatch 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 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.
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 retrieve 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
ReceiveMessageaction 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
ReceiveMessagerequest, 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
DelaySecondsparameter 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.