[jboss-dev] Further profling: Where should I focus?

Scott Marlow smarlow at redhat.com
Thu Dec 31 09:38:38 EST 2009

On Thu, 2009-12-31 at 00:14 -0600, Brian Stansberry wrote:
> On 12/30/2009 06:22 PM, Bill Burke wrote:
> >
> >
> > Ales Justin wrote:
> >>> IMO, we should just remove AOP entirely as our customers probably are
> >>>   not going to use it.
> >>
> >> This is exactly what will happen - remove AOP - if we disable it by
> >> default and re-write lifecycle handling to plain OO, w/o any costly
> >> pointcut matching.
> >>
> >> The only cost is lookup for potential @AOPEnable on the bean.
> >> While we still keep optional cool feature of creating an AOP proxy for a
> >> bean.
> >>
> >>> For @JMX just write another deployer and do it
> >>>   regularly.  Similarly with lifecycle and other features.
> >>
> >> Regularly?
> >> If you mean to register an mbean, that is actually not what we/users want.
> >> See my response to Dimitris this morning.
> >>
> >
> > There probably is a way to make AOP irrelevant to boot performance, but
> > you need to consider pluses and minuses nevertheless...Everybody
> > (thousands) of users are effected by boot performance, while only a
> > handful care about @JMX, etc.
> >
> True, but we use @JMX all over the place. I expect trying to get rid of 
> it and having all our POJO services register themselves in JMX will end 
> up sucking in most of the AS team, which will be a significant 
> distraction from EE 6 work. Personally I think we should explore further 
> whether this can be optimized before going down that path.
> >> While this could be a deployer feature, I think it's far more complex to
> >> do it than tie it into the bean's lifecycle.
> >> e.g. scan for @JMX, remembering the handle, checking if it's overridden
> >> for an instance, ... while we already have all this implemented in
> >> bean's lifecycle handling, it's just not optimized yet.
> >>
> >> What do you mean by "similarly with lifecycle and other features"?
> >> @JMX, @JNDI, @Password, ... is the lifecycle callback.
> >>
> >
> > All these annotations that trigger AOP.  Are they under the jboss
> > namespace?  Controlled by us?
> >
> Yes.
> > You might want to consider meta-annotations and turning @AOPEnabled into
> > one. i.e.
> >
> > @AOPEnabled
> > public @interface JMX {...}
> >
> > You look at the bean's class annotations, then look at those annotations
> > for @AOPEnabled.
> >
> >>> Again, if you want to take this route, I'd be happy to do the work.
> >>> I am willing to spend the next month on boot performance and AS.
> >>
> >> Excellent.
> >> So will I and the rest of MC team.
> >
> > Well, I need to know what I could do to help.  Is Kabir fine on the AOP
> > stuff?  VFS3 seems to be ok?  What about removing JMX Kernel Backward
> > Compatibility and upgrading services to MC?  I can tackle any of these
> > problems with little guidance I just don't want to be duplicating any
> > work (like with the deployer sorting).
> >
> Would converting mbean services help boot time, assuming that most still 
> need to expose a JMX interface, i.e. @JMX? Don't get me wrong, this is 
> something we need to do, but if your goal is to help boot perf I'm not 
> sure how much it will help.
> The JIRA for the boottime improvements we discussed in July is 
> https://jira.jboss.org/jira/browse/JBAS-7329. What are we doing on 
> limiting the scanning of our own classes? I see a number of deployments 
> without a jboss-scanning.xml.


JBAS-7030 represents that work and is mostly complete (subtask JBAS-7035
is still open).  

If you can, please review the changes associated with JBAS-7030 and give
me your feedback.  For what we did in June, I enabled the
AnnotationEnvironment trace logging and kept adding jboss-scanning.xml
until the AE boot time annotation scanning was eliminated.  As best as I
can tell, JBAS-7035 was ignored up until now.  

This took about 2 seconds off the AS boot.

Before: AS booted in 35s:304ms on my machine

After:  AS booted in 33s:324ms on my machine

We should enable the AE trace logging again and see which deployments
are now scanning for annotations.  

Are there any deployments that need the AE annotation scanning to be

> Alexey, could you use any help on XB optimization?

More information about the jboss-development mailing list