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

[Brian Stansberry]

On 12/31/2009 08:38 AM, Scott Marlow wrote:
> On Thu, 2009-12-31 at 00:14 -0600, Brian Stansberry wrote:
>>
>> 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.
>
> Brian,
>
> JBAS-7030 represents that work and is mostly complete (subtask JBAS-7035
> is still open).
>

Thanks; I remember the discussion but didn't see the JIRA. I linked that 
to JBAS-7329.

I was poking around last night and saw the missing stuff you've captured 
in JBAS-7035, plus a couple others (jmx-remoting.sar, mod_cluster.sar)

> 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.
>

I just used a debugger and put a breakpoint in 
AnnotationEnvironmentDeployer.deploy(), line 220, right after where it 
returns if the filter hasn't excluded the DeploymentUnit. I also added 
one in GenericAnnotationResourceVisitor.visit() which is where the 
heaviest part occurs.

The following (and their children) need excluding as 
GenericAnnotationResourceVisitor.visit() gets invoked:

snmp-adaptor.sar
mod_cluster.sar
juddi-service.sar
xnio-provider.jar
iiop-service.xml (which has a classpath element)

The ServiceBindingManager bindingservice.beans will need one too once it 
moves from conf/ to deploy/.

Besides all those, though, every -service.xml and -jboss-beans.xml is 
passing the filter. They don't trigger 
GenericAnnotationResourceVisitor.visit(), but the deployer does quite a 
bit of work, creating a ClassPool and GenericAnnotationResourceVisitor 
and executing the visitor. Kind of stuff that looks horrendous when you 
walk it in a debugger but probably doesn't take much time. But I expect 
that once we land the big fish, it's going to take 100 improvements in 
things like this to actually get a fast boot.

We could filter out all -service.xml and -jboss-beans.xml. Tricky thing 
is stuff like iiop-service.xml which doesn't package jars but includes 
them in its classpath. But TBH, in the real world is anyone going to 
package things that way *and* want annotation scanning?

Bottom line, this is an area that could use some attention, but probably 
won't be a big win. My feeling though is for the big picture stuff we 
need to wait for Ales to integrate the latest MC/deployers stuff 
(supposed to be in by Jan 8) and then we can see where we are. So, Bill, 
until then if you want to spend a couple days on something smaller, this 
is one.

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

If there are I'm sure they have tests in the testsuite that will fail if 
we mistakenly turn it off. :-D

>>
>> Alexey, could you use any help on XB optimization?
>>
>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development


-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat