Question 1 · choose 1
A worker on Amazon EC2 calls ReceiveMessage on an Amazon SQS standard queue in a tight loop. Most responses are empty, some are empty even though messages are waiting, and the SQS request bill keeps growing. The developer wants fewer empty and false empty responses without delaying messages that are already in the queue. What should the developer do?
- AIncrease the queue's visibility timeout to 10 minutes
- BSet WaitTimeSeconds on each ReceiveMessage call to a value up to 20 seconds
- CMake the queue a delay queue that holds each new message for 20 seconds
- DKeep short polling but call ReceiveMessage from more worker threads at once
Show the answer and why
AIncrease the queue's visibility timeout to 10 minutes
Incorrect
The visibility timeout only controls how long a received message stays hidden from other consumers. It does not change how ReceiveMessage looks for messages.
BSet WaitTimeSeconds on each ReceiveMessage call to a value up to 20 seconds
Correct
A wait time above 0 turns on long polling: SQS queries all servers and answers as soon as a message is available, which cuts empty and false empty responses. The maximum wait is 20 seconds.
CMake the queue a delay queue that holds each new message for 20 seconds
Incorrect
A delay queue keeps new messages invisible for the delay period, so it delays delivery instead of reducing empty responses.
DKeep short polling but call ReceiveMessage from more worker threads at once
Incorrect
Short polling samples only a subset of servers and returns at once, even when nothing is found. More callers make more requests, not fewer empty ones.
Long polling (WaitTimeSeconds or the queue's ReceiveMessageWaitTimeSeconds above 0) is the fix for empty responses and request cost.
AWS documentation