Amazon SQS supports two modes of polling for available messages: short polling and long polling. With long polling, the consumer specifies a timeout of 1-20 seconds to wait for available messages.
According to the documentation:
By default, Amazon SQS uses short polling, querying only a subset of its servers (based on a weighted random distribution), to determine whether any messages are available for a response.
Long polling offers the following benefits:
- Eliminate empty responses by allowing Amazon SQS to wait until a message is available in a queue before sending a response. Unless the connection times out, the response to the
ReceiveMessage
request contains at least one of the available messages, up to the maximum number of messages specified in theReceiveMessage
action.- Eliminate false empty responses by querying all—rather than a subset of—Amazon SQS servers.
- Return messages as soon as they become available.
The above characteristics make long polling seem pretty good. So is there a use case where short polling is preferable?
In particular, for high-throughput queues, is short polling faster than long polling?
By default, queues use short polling. With short polling, the ReceiveMessage request queries only a subset of the servers (based on a weighted random distribution) to find messages that are available to include in the response. Amazon SQS sends the response right away, even if the query found no messages.
In short polling, a response sampled on SQS ReceiveMessage call is returned immediately, even if the message queue is empty. But in long polling, a response sampled on SQS ReceiveMessage call is returned after a message is received in the queue, or after the long polling period has expired.
Long polling reduces the number of empty responses by allowing Amazon SQS to wait a specified time for a message to become available in the queue before sending a response. Also, long polling eliminates false empty responses by querying all of the servers instead of a sampling of servers.
FIFO queues provide exactly-once processing, which means that each message is delivered once and remains available until a consumer processes it and deletes it. Duplicates are not introduced into the queue.
Long polling is almost always preferable to short polling. Following are two use cases where short polling might be desirable(given in SQS FAQs):
From SQS FAQs:
In almost all cases, Amazon SQS long polling is preferable to short polling. Long-polling requests let your queue consumers receive messages as soon as they arrive in your queue while reducing the number of empty ReceiveMessageResponse instances returned.
Amazon SQS long polling results in higher performance at reduced cost in the majority of use cases. However, if your application expects an immediate response from a ReceiveMessage call, you might not be able to take advantage of long polling without some modifications to your application.
For example, if your application uses a single thread to poll multiple queues, switching from short polling to long polling will probably not work, because the single thread will wait for the long-poll timeout on any empty queues, delaying the processing of any queues that might contain messages.
In such an application, it is a good practice to use a single thread to process only one queue, allowing the application to take advantage of the benefits that Amazon SQS long polling provides.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With