JBAS-6105; Improve start-up time

[alesj]

Moving JIRAs (https://jira.jboss.org/jira/browse/JBAS-6105) posts to forum:

"Radim Marek" wrote:

Hi, I know you're probably trying to get JBoss AS 5.0 release out 'as soon as possible', but isn't a startup time and general performance quite important for initial reviews and feedback?

I'm asking because after trying to develop on 5.0.0.CR2 the 'slowdown' is noticeable and it's something that is actually quite annoying. As example, re-deployment of the packages for my latest project is significantly slower (50 - 75%) and more CPU intensive than with 4.2.3.GA. Tried both with JEE deployment on default profile and minimal profile with micro-container services. Haven't got any feedback for general on-the-fly performance.

I'm asking because although it's not valid comparison, I guess it would be easy to compare speed improvements with other open source application servers.

"alesj" wrote:

Radim, did you try the trunk?
We introduced VFS caching in between, which should speed up things considerably.

"Radim Marek" wrote:

Ales, I've just tested three configurations - 4.2.3GA, 5.0.0.CR2 and the trunk (as of today 2pm) - and can't see any significant difference in deployment speed using trunk, but the startup time is in average 2s longer than with CR2 (default profile).

Test is performed using custom EAR file (8 MB size) and 60MB WAR file. I'm now trying to establish some reasonable - easy to replicate test. Both test are having very simple deployment structure - so no Seam or things that would involve heavy pre-processing during deployment.

The WAR file I'm using is on average deployed in about 9 seconds on 4.2.3.GA, whereas more than twice that time on 5.0.0.CR2/trunk; significantly more utilizing CPU as well.

Test is performed using Java 5 and 6 on Mac OS X; and to have reference one test done on Java 5 / Solaris 10 (x86). Tomorrow I'll try to come back with more details.

"alesj" wrote:

I'm just about to commit MC changes - Kernel and Deployers. Deployers change will address scanning performance - if you have jboss-scanning.xml present it will scan accordingly to those rules. See Deployers project's test for jboss-scanning.xml usage.

Can you move this to a forum thead? Ales, I think the whole point is that by default the server should be fast for the majority of deployments. If you need to deploy extra descriptors and stuf, the game is lost.

[alesj]

Ales, I think the whole point is that by default the server should be fast for the majority of deployments. If you need to deploy extra descriptors and stuff, the game is lost.

Sure, but how else are you gonna know, if we need to scan or not?
Or what/where to scan?

e.g. afaik EJB3 deployments don't need any descriptors any more
It's the job of container to pick up EJB3 @annotations, hence you need to scan it all.
Unless user provides more detailed info about what/where to scan.
e.g. only scan my-ejbs.jar's org.acme.foo.ejbs package

But as you can see, I added ListDeploymentUnitFilter to scaning deployer (FilteredAnnotationEnvironmentDeployer),
so you're free to add any constraints to that chain. ;-)

[dimitris]

With the latest scanning filters the boot time has improved.

On my mid-range XP laptop I"m seeing.

minimal < 7secs
web < 20secs
default < 30secs
all < 50 secs

So we are good for now!

[dimitris]

See also https://www.jboss.org/community/docs/DOC-13178

[adrian.brock]

Something I noticed (by accident) is that for me to
bootstrap the default server it is about 40 seconds
on JDK5. But with JDK6 is 30 seconds.

With JBoss-4.2.x is see no difference.

So we are obviously tickling something inefficent
in JDK5 that has been fixed in JDK6?

[alesj]

I just found a minor bug in my new jboss-dependency.xml handling.
I'll do a new release to fix it.

Not that it's very critical, but I would at least like to not go GA with known MC bugz. :-)

I'll fix my blog to show this change as well. :-)
- http://in.relation.to/Bloggers/MicrocontainerGoes200GA

[alesj]

So we are obviously tickling something inefficent
in JDK5 that has been fixed in JDK6?

How to find this needle in JDK haystack? :-)

[adrian.brock]

"alesj" wrote:

So we are obviously tickling something inefficent
in JDK5 that has been fixed in JDK6?

How to find this needle in JDK haystack? :-)

I still see the two biggest hits as the VFS and aop pointcut matching
when I've measured it.

So for the VFS, I guess it would be that JDK6 no longer uses memory mapped files
for jars.
For the AOP pointcut matching it would be the reflection calls.