Is SQS short polling ever preferable to long polling?

augurar picture augurar · Jul 23, 2018 · Viewed 10.9k times · Source

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?

Answer

user818510 picture user818510 · Jul 23, 2018

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.