AWS SQS - use case for "short polling"

Question

When using event driven processing of work with AWS SQS and worker clients. the use of long polling is often recommended. AWS documents this here

Essentially when there are no message in the queue, the worker does not need to keep making requests to the queue (this reduces call costs), but new messages are still delivered immediately to a worker that is long polling.

Having build small systems a couple of times with SQS now, I question what the benefit of short polling is. I imagine it may be slightly faster, as only a subset of SQS servers are polled when short polling, but if that is the only downside, what sort of additional delay am I looking at? Does it depend on the number of messages I am processing? (Does SQS servers scale based on the number of messages?)

What other downsides are there, if any?

Answer 1

While you can benchmark this yourself, benchmark testing has shown that there isn't much of a difference in time between long and short polling when the queue is full. Additionally, with long polling you always have data coming back unlike short polling.

As for when to use short polling the AWS FAQ covers this:

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.

Additionally:

..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.

If you don't want to deal with asynchronous queues and multiple threads handling the queues in your application then short polling may provide an easier development path (although you'll have to deal with empty responses).