Embeded JOPR causes CPU load in JBoss 5.1.0

[xmedeko]

Hi,

I have tried new JBoss 5.1.0 and have observed, that it causes much more CPU than JBoss 5.0.1 when it is idle (no connection from clients). This CPU load is not constant, just every few seconds the CPU load jumps up to 15-18% (Intel Pentium 1400MHz), and then falls down to zero. So I have tried to remove the administration console and voila , the CPU load was down, like in the JBoss 5.0.1.


Also, any work with embeded JOPR console was very very slow - only the first view of the login page has taken more than 5sec.

And the last: the start of the JBoss 5.1.0 without administration console is remarkably faster.

Does anybody else observed similar problems?

[ccrouch]

"xmedeko" wrote:

I have tried new JBoss 5.1.0 and have observed, that it causes much more CPU than JBoss 5.0.1 when it is idle (no connection from clients).

We've gone to a great deal of trouble to try to ensure that the console does not do any work when it is not being used, so we're very interested to find out more details about the CPU usage you are seeing.

"xmedeko" wrote:

This CPU load is not constant, just every few seconds the CPU load jumps up to 15-18% (Intel Pentium 1400MHz), and then falls down to zero. So I have tried to remove the administration console and voila , the CPU load was down, like in the JBoss 5.0.1.

If you could do a threaddump during one of these CPU spikes and then attach the output to a new jira (https://jira.jboss.org/jira/browse/EMBJOPR) I think that will help us to locate any issue.

"xmedeko" wrote:

Also, any work with embeded JOPR console was very very slow - only the first view of the login page has taken more than 5sec.
And the last: the start of the JBoss 5.1.0 without administration console is remarkably faster.

The console is designed to start up lazily and have an absolute minimal impact on the start up time of the App Server. When the App Server is started the console war will not get fully deployed (e.g. Seam will not even be loaded). In our testing the difference between starting the App Server with and without the console is around 2 or 3 seconds. This time difference is due to initialization of the JSF parts of the console app which were deemed excessively difficult to initialize lazily. If you are seeing differences of more than 2 or 3 seconds please create a new jira at https://jira.jboss.org/jira/browse/EMBJOPR and attach the console output of your different runs.

When a request is first made to the console the application will be initialized. The first stage is loading Seam and the app itself. We've typically seen this take around 15seconds. At this stage the login page will load. After you have entered your credentials the app will query the JBAS instance to find what is deployed and build up the inventory which you will navigate through when administering the JBAS instance. Again in our testing this second stage takes around 15seconds. After that the app is fully loaded and ready to run. We've not seen any significant latency in using the app once it has started up. If you see particular requests take a long time then again please raise a jira and include details and server.log output.

A total app start time of around 30secs is longer than we would like to see, even though it is a one time cost and will not occur unless you make a request to the console. Therefore we are investigating how to speed up the start time further. If you want to keep track of progress I suggest you watch the following jira: https://jira.jboss.org/jira/browse/EMBJOPR-171

Thanks for taking the time to try out the console and we're looking forward to more of your feedback.

Cheers

[xmedeko]

JBoss boot time - about 5 sec difference on Pentium dual-core @2.5 GHZ.

https://jira.jboss.org/jira/browse/EMBJOPR-186

I will tests other issues from this thread later.

[xmedeko]

CPU and Memory spikes:

http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234753#4234753



I guess the e/JOPR vastes a lot of memory which causes troubles to the garbage collector, which causes CPU usage spikes. See pictures attached to this bug. Or try to observe JBoss by jconsole tool.