> A little more CPU usage compared to no UUID namespace configuration at all, or compared to the old temp. queue namespace?
Both. Justin On Fri, Oct 31, 2025 at 8:33 AM Vilius Šumskas <[email protected]> wrote: > A little more CPU usage compared to no UUID namespace configuration at > all, or compared to the old temp. queue namespace? To correct my previous > statement, we *migrated* from temp. namespace to new UUID namespace > configuration. > > -- > Vilius > > -----Original Message----- > From: Justin Bertram <[email protected]> > Sent: Friday, October 31, 2025 3:11 PM > To: [email protected] > Subject: Re: Performance impact of connection router > > There will be a little more CPU usage when using the uuid-namespace since > the broker has to detect the UUID, but again, I wouldn't expect that to be > significant. > > > Justin > > On Fri, Oct 31, 2025 at 1:58 AM Vilius Šumskas > <[email protected]> > wrote: > > > Oh, and one more thing, we also started using the new UUID namespace > > configuration and security rules in 2.42.0. But I guess that should > > not be a problem performance wise(?). Most of our connections use > > temporary UUID queues to reply to. > > > > -- > > Vilius > > > > -----Original Message----- > > From: Vilius Šumskas <[email protected]> > > Sent: Friday, October 31, 2025 8:51 AM > > To: [email protected] > > Subject: RE: Performance impact of connection router > > > > I didn't at the moment, but I will try to change configuration on our > > production system during next maintenance window to see how it affects > > CPU utilization. > > > > The reason I'm asking is that I started to investigate why one of our > > clusters has a considerable CPU usage, even though the throughput load > > (message count and size) is not that big at all. It is either: > > a) a connection router configuration we recently introduced, or > > b) something changed on the application side, maybe how developers > > close and open connections, or something like that. > > > > -- > > Vilius > > > > -----Original Message----- > > From: Justin Bertram <[email protected]> > > Sent: Friday, October 31, 2025 5:18 AM > > To: [email protected] > > Subject: Re: Performance impact of connection router > > > > The performance impact is hard to judge, but I wouldn't expect it to > > be much as it really just adds one invocation of > > java.util.regex.Matcher#matches for every connection. > > > > Have you conducted performance tests with and without the router? If > > so, what did you find? > > > > > > Justin > > > > On Thu, Oct 30, 2025 at 6:12 PM Vilius Šumskas > > <[email protected]> > > wrote: > > > > > Sorry last message went unfinished to the list. > > > > > > --- > > > > > > We are using Artemis router: > > > <connection-router name="deny-privileged-users"> > > > <key-type>ROLE_NAME</key-type> > > > <local-target-filter>^(?!amq$).*$</local-target-filter> > > > </connection-router> > > > > > > to filter out unwanted users from connecting to one of our acceptors. > > > > > > I'm wondering, what is the performance impact of such router if we > > > have large amount of non-persistent connections from the clients? We > > > have ~3k connections at the moment with a fair amount of them > > > constantly disconnecting and connecting as per business requirements. > > > Connections are TLS protected, if that make a difference. > > > > > > -- > > > Vilius > > > > > > -----Original Message----- > > > From: Vilius Šumskas <[email protected]> > > > Sent: Friday, October 31, 2025 1:03 AM > > > To: [email protected] > > > Subject: Performance impact of acceptor router > > > > > > Hi, > > > > > > we are using router: > > > > > > -- > > > Pagarbiai, > > > > > > Vilius Šumskas > > > Rivile > > > IT vadovas > > > +370 614 75713 > > > > > > > > > -------------------------------------------------------------------- > > > - To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] For > > > further information, visit: https://activemq.apache.org/contact > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] For > > further information, visit: https://activemq.apache.org/contact > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > For further information, visit: https://activemq.apache.org/contact > >
