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
