Re: [jboss-dev] Further profling: Where should I focus?
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat