Is SQS short polling ever preferable to long polling?

Question

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 the ReceiveMessage 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?

Pastime

Answer 1

Long polling is almost always preferable to short polling. Following are two use cases where short polling might be desirable(given in SQS FAQs):

• When immediate message processing is required.
• When you poll multiple queues in a single thread.

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.

Ottoman

"When immediate message processing is required," isn't quite correct. It should be something like, "when the call to ReceiveMessage must return immediately". Long-polling actually allows for more immediate processing of messages than short polling. Note the "return messages as soon as they become available" in the questions quoted AWS docs. – Quetzal

What exactly is the cost differential between short and long? – Bidding

@JatinMorar mainly cost of empty receives, exact number will be depending on the actual use case. – Chlorophyll