[jboss-dev] Further profling: Where should I focus?
brian.stansberry at redhat.com
Thu Dec 31 12:45:30 EST 2009
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.
> 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
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:
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
> Are there any deployments that need the AE annotation scanning to be
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
Lead, AS Clustering
JBoss by Red Hat
More information about the jboss-development