We have been experimenting with different approaches: 1) Using a prefetch of 50 2) Using a prefetch of 1000 3) Using a prefetch of 0 and doing manual flow control, issuing 1000 credits initially
Interestingly, throughput seems to actually go down the more credit we issue, i.e. option 1) yields the best result ... vertx-proton seems to replenish the sender (Dispatch Router in this case) with one credit each time a message is processed at the cosumer side when using prefetch. Do you consider this to be a problem, i.e. wouldn't it be more efficient to replenish the sender with, say, 200 more credits en block once in a while? Mit freundlichen Grüßen / Best regards Kai Hudalla Chief Software Architect Bosch Software Innovations GmbH Schöneberger Ufer 89-91 10785 Berlin GERMANY www.bosch-si.com Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B; Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn ________________________________________ From: Gordon Sim <g...@redhat.com> Sent: Friday, July 14, 2017 10:14 To: users@qpid.apache.org Subject: Re: Dispatch Router throughput On 14/07/17 09:07, Hudalla Kai (INST/ECS4) wrote: > Sadly, though, it doesn't at all match what we are experiencing using > a vertx-proton based Java sender and consumer where we currently seem > to not get above 2500 m/sec. I hope that either our test setup is > completely wrong or that our usage of vertx-proton is erroneous. That's an order of magnitude off what you should be able to get. How much credit is your receiver issuing? --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
