Thank you for your thoughts. So I will consider the behavior of ActiveMQ Artemis the desired one and be more specific in the future with the client settings.
Sebastian -----Ursprüngliche Nachricht----- Von: Clebert Suconic <clebert.suco...@gmail.com> Gesendet: Donnerstag, 30. Mai 2024 20:37 An: users@activemq.apache.org Betreff: Re: Performance issue with Artemis 2.28 I’m having a DejaVoux on this. I guess at some point we missed a round trip somewhere. Some sync options at the serverlocator could have an effect. It would be difficult to find the difference at this point. Clebert Suconic On Wed, May 29, 2024 at 4:10 PM Justin Bertram <jbert...@apache.org> wrote: > I'm glad you got your issue sorted. I would expect setting > consumerWindowSize=0 to slow down consumer processing potentially > quite a lot depending on your use-case. > > I worked on HornetQ, and I'm not sure why it behaved differently. > There's been over 10,000 commits in the code-base since then so while > a lot of things are different a lot has changed as well. At this point > I'm not sure it's worth the effort to determine why. The behavior > you're seeing now is what I would expect. > > > Justin > > On Mon, Apr 22, 2024 at 9:02 AM <s.go...@inform-technology.de> wrote: > > > Okay, > > > > > > > > I am answering my own question after some more research. > > > > The problem was the consumerWindowsSize of the client consumers. > > This was set to 0 leading to no buffering at all and a server > > round-trip for each retrieve call. > > > > After increasing window size to half a megabyte, the performance > increased > > significantly and the clients were able to process fast enough. > > > > > > > > This is sort of weird as we had the exact same configuration with > > HornetQ and no performance bottleneck with the same number of consumers. > > > > Maybe someone of the old HornetQ crew has an idea why this is different. > I > > know it’s a different product but many of the internals seem to be > > the > same. > > > > > > > > Kind regards > > > > > > > > Sebastian > > > > > > > > From: s.go...@inform-technology.de <s.go...@inform-technology.de> > > Sent: Montag, 22. April 2024 08:45 > > To: users@activemq.apache.org > > Subject: Performance issue with Artemis 2.28 > > > > > > > > Good morning group. > > > > > > > > We encounter a performance issue with ActiveMQ Artemis. The system > > was formerly a JBoss HornetQ installation and was migrated to > > AciveMQ Artemis and with HornetQ we had no issues at all > > > > > > > > The performance issue is about a multicast address with a single > > queue that has 10 consumers all residing in the same JVM. > > > > This JVM uses a single ClientSessionFactory and each of the > > consuming worker threads has its own session. > > > > The throughput is not as we had expected it to be and somewhere > > around 50 messages/second. > > > > After some profiling I found out, that most of the time the worker > threads > > using that 10 consumers are standing in > > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.rece > > ive > > (~111ms) while processing the message takes around 23ms. > > > > > > > > My question is: can we have each consumer pick one of the messages > > in the queue while some messages are already processed? > > > > or in other words: does Artemis deliver message 2 while message 1 is > > not yet acknowledged? > > > > > > > > > > > > Kind regards > > > > Sebastian Götz > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org For additional commands, e-mail: users-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
