Is the SQS poller buffering messages to maximise throughput?

[will-molloy]

Hi AWS! We have quite a few queue processors and I'm wanting to migrate them to this framework 😄. I wanted to confirm if it would meet our throughput requirements.

A naive way to implement an SQS poller is as follows (similar to the code in this blog):

• Send receive request and receive say, 10 messages
• Process the 10 messages in parallel
• After all messages are processed, send the next receive request

This has the following downsides:

• While polling the queue, nothing is being processed (i.e. when sending and waiting on receive requests)
• Waits for the slowest message to be processed before polling again (i.e. worker threads are idle)

So we have a pattern using Channel (essentially an in-memory buffer) which works as follows:

• Channel writer (worker thread) polls SQS and continuously writes to the Channel (up to a maximum size)
• Channel readers process the messages individually
  (The number of writers and readers can vary, but it's typically 1:10, with channel size 10.)

This avoids the downsides mentioned above.

Does this framework use a similar pattern?

[normj]

Hi @will-molloy. The framework uses different flows and terms but I believe gives the same results your are saying. There is an SQS poller and a message manager that is in charge of keeping track of the messages being processed and possibly extending the message visibility. The manager is also the controller of how many messages can be processed in parallel.

The SQS poller is always monitoring the message manager to see if there is any available space for more messages to run as messages complete. Assuming there is it will poll for the number of available messages that manager can handle and then pass them to the manager. We want to avoid reading more messages from SQS then we can currently process forcing messages to wait in memory when possibly another instance of the application could read the messages and process them.

So short answer is no it does not read a full batch, wait for the batch to complete and then read another batch. It will read more messages as messages get completed.

[will-molloy]

Oh that's great.

when possibly another instance of the application could read the messages and process them.

So it's even better than our flow :)