Java app slow performance within JMX

[duncanferguson]

I am working on a multi-threaded app that transforms and persists data using hibernate. I wrapped the app with an MBean and deployed it on JBOSS to some simple management (setting the number of threads to use/starting the app etc).

When running with JBOSS with a reduced number of services (basically everything removed apart from JMX components, JMX Console and Jetty) the app performs 3 times slower. The code that is deployed on JBOSS has not been altered to work within JBOSS, the only addition being my MBean interface & implementation.

Can anyone shed any light on why I maybe be seeing this reduction in performance?

I am using jdk1.4.2, jboss 3.2.1, Linux.

Thanks in advance for any suggestions.

[adrian.brock]

Get a profiler and post some real numbers.

There is no way using a JMX invoke is three times slower
than db access.

Regards,
Adrian

[duncanferguson]

Thanks for the reply.

Im not sure you followed my first posting. I am not comparing the performance of db access to JMX invoke rather I am comparing the performance of the application inside and outside JBOSS.

If I am measuring the perfomance in terms of inserts to the db achieved, the number of inserts (after various transformations) goes from 1700 with the app running standalone to approx 500 when the app is running with JBOSS.

The only thing that shows up on the profiler is the DeploymentScanner which takes approximately 20% of CPU. This certainly doesnt account for the performance degradation by a factor of 3. Coudl there be something else i am not picking up on?

I realise there must be some performance reduction when running within JBOSS - my profiler shows lots of active threads that JBOSS kicks off (JNP Server, Session Scavengers etc). Is it just the case that the JVM is having to cope with this extra threading activity resulting in reduced performance when compared to running the app standalone with a dedicated JVM?

And if so has anyone noticed/documented this before?

[adrian.brock]

I was joking about the db, an application performing
db operations will spend most of its time in the db.

You are looking for waits (monitor contention) not cpu usage
the background threads should have no affect.

Do you do lots of classloading?

Regards,
Adrian

[duncanferguson]

All neccessary class loading is done in the initial period of the run. There is no monitor contention going on (according to JProfiler). Any other ideas? Thanks for your help.

[adrian.brock]

Can you post the differences in runtime for the methods in original
and new apps.
If you can show real times rather than cpu times that would help.

Regards,
Adrian

[duncanferguson]

The problem seems to be because logging properties for hibernate are in someway being overridden by jboss's configuration.

This is resulting in all invocation hibernate makes of org.apache.commons.logging.Log.isTraceEnabled() returning true when runnning in JBOSS environment. Any idea of how to stop this? Thanks for your help.

[adrian.brock]

in conf/log4j.xml

<!-- Limit org.apache, org.jboss, org.mortbay, org.javagroups, etc. categories to INFO -->




Regards,
Adrian

[duncanferguson]

Cheers Adrian,

Just for the benefit of anybody else the actual bit that goes in log4j.xml is: