On Fri, 10 Jul 2020 at 16:54, Gordon Sim <g...@redhat.com> wrote: > > On 10/07/2020 4:03 pm, tomt wrote: > > Thanks for the fast response. I spent a good part of the afternoon looking > > into the whole flow control system to understand better given what you had > > asked. > > > > I am using the Python client as my receivers and the C++ API as my senders > > who each synchronously send on their own threads as fast as possible. > > Which c++ API? proton? And when you say 'synchronously' what do you mean > exactly? Are you waiting for the acknowledgement of one message before > sending the next? > > The python client is by far the slowest, though I am still surprised by > your numbers there. I would expect better even from python, especially > if there are more than one of them (or are they each getting all the > messages?). > > > I dug a little deeper and found the Python client starts off receivers with > > 10 credits as the default since I have not taken credits into account for > > anything I've done so far. I am having an assumption here that increasing > > the number will increase my throughput, but I think I still lack some > > general understanding here. > > A window of 10 is not terrible but I would expect you to get better > numbers if you increase it to 100 or 250 (probably won't make much > difference above that). > > > > > If I have multiple receivers subscribed to a given topic and they each have > > some X amount of credits, how does the sender account for this when sending? > > Some receivers could be slower in replenishing credits than others and the > > sender only sends to the topic and has no idea how many receivers there are. > > After further looking at the examples and AMQP 1.0 spec, it doesn't seem > > like I have much ability at all to control credits from the sender side at > > all. Do you have anything I can look at to learn more about the flow > > control feature? > > Credit is always issued by the process receiving messages. So for the > senders, it is the router or the broker that will grant them credit. The > broker and the router behave in quite different ways, but as you are > seeing the same low rate in each case I don't think it is the server > side that is the issue. >
I read the original message as being not an either/or case of broker and router, but the setup always having both? Again points to some more detail on how things are configured being useful. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
