DroidB2

DroidB2

Hello, I am not sure the problem is in the library, but maybe you could help me in what way should i research.
We use broadway_sqs library for amazon sqs.
we measure time to deliver for each message separately on the application side. Time to deliver may be up to 20 seconds!
So the question is, what may it take so long?
[{“delivered”:0.0},{“delivered”:6.0},{“delivered”:10.0},{“delivered”:10.0},{“delivered”:9.0},{“delivered”:9.0},{“delivered”:10.0},{“delivered”:9.0},{“delivered”:9.0},{“delivered”:10.0},{“delivered”:10.0},{“delivered”:9.0},{“delivered”:11.0},{“delivered”:10.0},{“delivered”:9.0},{“delivered”:11.0}]

Showing Posts 1 to 9

benwilson512

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

Can you elaborate exactly how you’re measuring delivered?

Also keep in mind that by default broadway_sqs is configured to process messages in batches, up to some time limit. If your volume of messages is very low, you may be waiting for the time limit to hit.

DroidB2

DroidB2 OP

measuring is very simple:

  • track time before we put in queue via ex_aws library
    {:ok, %{body: %{message_id: message_id}}} = ExAws.SQS.send_message(queue_url, message) |> ExAws.request()
  • track time inside method process_data
    def handle_message(_, message, _) do
    message
    |> Message.update_data(&process_data(&1, message.metadata.message_id))
    end
benwilson512

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

Can you show the code you have that sets up broadway?

DroidB2

DroidB2 OP

Broadway.start_link(__MODULE__,
      name: __MODULE__,
      producer: [
        module: {
          BroadwaySQS.Producer,
          queue_url: Keyword.get(config, :queue_url), config: Keyword.get(config, :credentials)
        },
        stages: 10
      ],
      processors: [
        default: [stages: 100]
      ],
      batchers: [
        default: [
          batch_size: 10,
          batch_timeout: 2000
        ]
      ]
    )
benwilson512

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

Right, so at a minimum if you aren’t sending more than 10 messages you’ll have a wait time of at least 2 seconds, since that’s the batch timeout. The other delays you mentioned of up to 20 seconds sound a lot like the max value for the SQS wait_time_seconds option. You aren’t setting it explicitly, but the queue itself will also have a default. What is the queues ReceiveMessageWaitTimeSeconds value?

DroidB2

DroidB2 OP

ReceiveMessageWaitTimeSeconds = 0

If there are batchers, the acknowledgement is done by the batchers, using the batch_size

I thought batch_size needs only for acknowledgement, to collect all messages in a batch

benwilson512

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

I don’t understand your question sorry.

DroidB2

DroidB2 OP

Even if you are not interested in working with Broadway batches via the
handle_batch/3 callback, we recommend all Broadway pipelines with SQS
producers to define a default batcher with batch_size set to 10, so
messages can be acknowledged in batches, which improves the performance
and reduce the costs of integrating with SQS.

Sorry for my english, batch_size and batch_timeout do not block producer to receive more messages. These params used only for acknowledgment (request to sqs in the end of pipeline)

burntham

burntham

We have observed the same thing, especially when we only have 1 or 2 messages being sent to the queue every now and then.

For us the issue was broadwaySQS’s default polling (short polling) and receive_interval (5 seconds).
The default behaviour sees a broadway producer polling sqs for messages and on an empty receive, waiting 5 seconds before trying again.

If there are very few messages in the queue short polling does not guarantee you will get any messages since it only queries a subset of the servers that make up your SQS queue. That means it can take multiple attempts to get a single message. In our case, that meant our broadway producer would take between 2 and 60 seconds to receive a message when there was only 1 enqueued.

We needed the best response time possible and were able to achieve it by reducing the receive_interval to 50 ms and setting the wait_time_seconds to 20.
Note: for receive_interval doesn’t seem necessary with long polling and we wanted the value close to 0, but it would probably work with 0.
for wait_time_seconds: any number above 0 enables long polling SQS long polling docs. Long polling is guaranteed to not return an empty receive if there are any messages in the queue and it will return as soon as any messages are available.

For example:

producer: [
        module: {
          BroadwaySQS.Producer,
          queue_url: Keyword.get(config, :queue_url), config: Keyword.get(config, :credentials), 
          wait_time_seconds: 20
          receive_interval: 50
        },
      ],
— All posts loaded —

Where Next? Top

Trending in Questions Top

RSP87
I’m working on a project that simulates the bumbl example in the programming phoenix book. It acts almost like an email client. We have a...
New
nseaSeb
Hello, I know there is an approach for handling lists that allows for optimized traversal, but I can’t recall the specific method (somet...
New
RemyXRenard
I’m seeing that a list inside a Kino.DataTable will be interpreted as a charlist, even if the Kino.configure() is set to charlists: :as_l...
New
brecabral
Documentation While reading the Scoped Routes section, I noticed that the documentation currently refers to a problem without explainin...
New
velrest
So my question is quite simple and i have found no conclusive answer on forum, google or AI. Should we use :erlang.float for Integer to ...
New
samoloth
Hi, I’ve just set up an application with ash_authentication. There is only magic link strategy for now, so there is no confirmation add o...
New
FlyingNoodle
If a change or preparation module uses Ash.Changeset.get_argument/2 or Ash.Query.get_argument/2 (or any of the other get_argument functio...
New

Other Trending Topics Top

mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
webofbits
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself. My main conc...
#ai
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews