activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Bertram <jbert...@apache.com>
Subject Re: Artemis use of PhantomReference impacting GC performance
Date Thu, 04 Feb 2016 19:44:56 GMT
Thanks for explaining your use-case a bit more.  That helps.  In my opinion the key statement
here is that Artemis isn't working in a vacuum - it actually plays quite a small role in a
much larger application.  Your overall use-case involves low message volume and low latency
requirements.

Can you elaborate any more on what specifically the JMS related code is doing?  For example,
are you using transactions?  What connection factory are you using?  Are your clients local
or remote or both?  How many clients do you have and what kind are they (e.g. producer or
consumer)?  The more information you can provide the more likely it is we will be able to
help.  

Personally I think comparing Artemis to JBoss Messaging is not terribly useful.  We're talking
about implementation level details here as they are related to GC.  We're not going to move
back to JBoss Messaging's architecture and we're not going to drop Netty so let's focus on
things we might actually be able to change.  It may be that your client code can be optimized
or written differently to take advantage of how Artemis is implemented or it may be that you
need to tune the GC differently.  We can't help much without more data about your use-case,
application, environment, etc.  Performance related issues like this are typically the most
difficult to work through, especially on a mailing list.  If you could provide an actual test
demonstrating a problem that would be ideal.


Justin

----- Original Message -----
From: "jim_b_o" <james@inaseq.com>
To: dev@activemq.apache.org
Sent: Thursday, February 4, 2016 12:17:35 PM
Subject: Re: Artemis use of PhantomReference impacting GC performance

I think the memory comparison is fair in this case.  The main application
load is events received via a ResourceAdapter passed to POJOs which process
and return responses via the same ResourceAdapter.  There is no Web
component and EJBs are only for admin functions and not being invoked during
these tests.  The JMS is an outbound feed of a small subset of the processed
events.  So the only container code under test is the JMS and a small part
of the ResourceAdapter glue although most of that is done using Spring and
is the same in both containers.  The POJOs and ResourceAdapter are identical
in both systems.

This does impact application performance.  I don't doubt that Artemis can
handle more messages and do so faster than the old messaging but it is not
operating in a vacuum.  The JMS performance is not a critical aspect of this
system.  The critical aspect is how quickly and reliably the POJOs can
receive/process/respond via the ResourceAdapter.  These longer
stop-the-world GCs that appear to be due to the JMS cause hick-ups in that
processing.  The JMS is doubling the GC pause time.

I'll run another test to confirm if the excess PhantomReferences are from
Netty or XNIO.  I'm currently connecting the JMS and EJB client
simultaneously so I'll separate them.



--
View this message in context: http://activemq.2283324.n4.nabble.com/Artemis-use-of-PhantomReference-impacting-GC-performance-tp4706961p4706976.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Mime
View raw message