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

Wed Jan 13 10:30:14 EST 2010

As of this morning, I have a full AS instance running with VFS3 based on all the integration branches.  I have a few more things to work through (ex. over active hot re-deployment), but it appears everything else is functional.  I plan to run it through a  series of deployment test to find the rest of the oddities.  

As for boot time, it appears to be booting around 23 seconds for the default profile and under 5 for the minimal profile (~3 seconds for Legacy JMX Core to initialize).  

John

On Jan 13, 2010, at 8:29 AM, Bill Burke wrote:

> i am seeing the same.  What I saw pre-merge was that the deployer 
> sorting brought boot time from 30-33 to 26-28.  With the changes I'm 
> seing 23-24.  10-20% improvement is about where I thought we'd be with 
> AOP changes.
> 
> Great job Ales, Kabir and company!
> 
> Jaikiran Pai wrote:
>> With the recent upgrade of MC in AS trunk, the "default" config on my 
>> system now boots in around 23 seconds consistently. Before the upgrade 
>> it used to take somewhere around 30 to 33 seconds.
>> 
>> -Jaikiran
>> 
>> Kabir Khan wrote:
>>> I forgot to mention the changes that I did for JBKERNEL-75, i.e. lifecycle: http://community.jboss.org/message/518409#518409
>>> 
>>> The gist of it is that <lifecycle-configure/> & friends no longer can take an 'expr' attribute (containing a pointcut) and that the 'classes' attribute now must take an annotation.
>>> 
>>> On 5 Jan 2010, at 18:08, Kabir Khan wrote:
>>> 
>>>> The work for this has been committed against https://jira.jboss.org/jira/browse/JBKERNEL-75 and https://jira.jboss.org/jira/browse/JBKERNEL-74. I have a few things I need to do before the end of the week, if I have any time I'll try to see what impact this has on AS boot time.
>>>> On 4 Jan 2010, at 17:28, Kabir Khan wrote:
>>>> 
>>>>> I tried starting AS with the updated jboss-aop-mc-int.jar, but ran into problems with dependencies. I'll work on the @JMX stuff next, and try to see if I can update all the dependencies locally in AS once I'm done with that if I have some time before our release
>>>>> 
>>>>> On 4 Jan 2010, at 15:43, Kabir Khan wrote:
>>>>> 
>>>>>> I think I've got the bypassing proxy stuff working now both with and without weaving. I'm re-running some tests before committing. A summary of what I have done;
>>>>>> 
>>>>>> -AOP proxy creation/checks is disabled by default
>>>>>> - at EnableAopProxy on a bean forces it to go through the proxy checks
>>>>>> - at DisableAOP is deprecated, but will stil be checked if it is present and the new annotations are not present
>>>>>> 
>>>>>> A few points:
>>>>>> -if a bean is not woven but has constructor aspects you want invoked, the bean needs the @EnableAopProxy annotation
>>>>>> -If a bean's class is woven it can have aspects, so we will always check the AOP dependencies for that bean. This will only happen if loadtime weaving was turned on (or compile-time weaving was used) AND the bean matches some pointcuts, so it should not be an issue in practice.
>>>>>> 
>>>>>> Once I've tidied up I'll commit to MC trunk, and try putting it into AS trunk before moving on to replacing the mechanism for AOP lifecycle.
>>>>>> 
>>>>>> On 24 Dec 2009, at 12:29, Kabir Khan wrote:
>>>>>> 
>>>>>>> I've made a start on this, but doubt I'll finish it before I finish for Christmas. I am deprecating the @DisableAOP annotation. By default aop proxies will be disabled, but can be enabled with @EnableAopProxy. Lifecycle callbacks will be enabled by default (and I'll come up with a quicker way of determining if they should apply), but can be disabled using the @DisableAopLifecycle annotation. 
>>>>>>> 
>>>>>>> One issue that I need to look into is that there are a bunch of tests that run with weaving enabled, so I need to see how they fare with this new setup. Since if they are woven, aspects will apply, and if those aspects have dependencies we need those in AOPDependencyBuilder. 
>>>>>>> 
>>>>>>> 
>>>>>>> On 24 Dec 2009, at 10:47, Ales Justin wrote:
>>>>>>> 
>>>>>>>>> +1, disable AOP wherever possible. 
>>>>>>>> I guess we can go the other way now, disabled by default + make 
>>>>>>>> lifecycle completely OO.
>>>>>>>> We should then definitely see good improvement.
>>>>>>>> 
>>>>>>>>> And I'd even dare say if you want @JMX, why not just 
>>>>>>>>> implement it the old fashion with MBean interfaces? It's simple and fast :-)
>>>>>>>> You got that right, it's simple, probably too simple. ;-)
>>>>>>>> I think one would still like to use the real power of POJO and IoC and
>>>>>>>> just register it to MBeanServer for some simple admin/config.
>>>>>>>> 
>>>>>>>> I dare to say I think you need to re-read this article :-)
>>>>>>>> * http://java.dzone.com/articles/a-look-inside-jboss-microconta-0
>>>>>>>> _______________________________________________
>>>>>>>> jboss-development mailing list
>>>>>>>> jboss-development at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>> _______________________________________________
>>>>>>> jboss-development mailing list
>>>>>>> jboss-development at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>> _______________________________________________
>>>>>> jboss-development mailing list
>>>>>> jboss-development at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>> 
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>> 
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development

--
  John Bailey
  JBoss by Red Hat
--