Are you measuring this during a sustained load period? Measuring things like this during a ramp up will be likely cause false positives (as netty for instance would still be bootstrapping the reusable pool area).
I know someone with a lot of experience on turning parallel GC, and I'm gathering some information for this thread. (I will ask him to post here). Also: you were with JBoss 4. You probably also have different JDKs now. so perhaps different settings would be required for your load? On Thu, Feb 4, 2016 at 2:44 PM, Justin Bertram <jbert...@apache.com> wrote: > 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" <ja...@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. -- Clebert Suconic
