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


Reply via email to