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.receive > (~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 > > > >
