[jboss-user] [JBoss Microcontainer Development] New message: "Profiling the dependency project"

Kabir Khan do-not-reply at jboss.com
Tue Feb 9 07:53:14 EST 2010


User development,

A new message was posted in the thread "Profiling the dependency project":

http://community.jboss.org/message/525047#525047

Author  : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com

Message:
--------------------------------------------------------------
Since the indexing dependency resolver I have been working on does not yield the performance improvements I was hoping for, I am now benchmarking the dependency project in isolation. It makes profiling a lot easier since there is a lot less other things going on which is the case when starting up the application server. My thinking now is that we should do the same for the other MC modules.
 
One thing is to not try to resolve contexts that are in the INSTALLED state (or where the , from AbstractController.resolveContexts(boolean), this shaves off about 20% for contexts installed in the right order. See http://community.jboss.org/message/524747#524747 for a description of the benchmark.
 
         for (ControllerState fromState : stateModel)
         {
            ControllerState toState = stateModel.getNextState(fromState);
-            if (resolveContexts(fromState, toState, trace))
+            
+            if (stateModel.isValidState(toState))
            {
-               resolutions = true;
-               break;
+               if (resolveContexts(fromState, toState, trace))
+               {
+                  resolutions = true;
+                  break;
+               }
            }
         }
      }
 
Another simple thing that cuts deploying 2000 contexts
-with dependencies in the right order from 852ms->789ms
-with dependencies in the right order from 12788ms->8320ms 
is to further modify resolveContexts to not break out of the loop once it resolves some contexts for a state, e.g.
 
      boolean resolutions = true;
      while (resolutions || onDemandEnabled)
      {
         if (onDemandEnabled)
            wasOnDemandEnabled = true;
 
         onDemandEnabled = false;
         resolutions = false;
         for (ControllerState fromState : stateModel)
         {
            ControllerState toState = stateModel.getNextState(fromState);
 
            if (stateModel.isValidState(toState))
            {
               if (resolveContexts(fromState, toState, trace))
               {
                  resolutions = true;
//                  break;  // Don't exit here
               }
            }
         }
      }

Profiling this for 500 contexts reduces the number of calls to the nested resolveContexts from
-17,500 to 7000 (right order)
-17,500 to 10,493 (wrong order), a bit down the line we end up with 377K instead of 627K calls to resolveDependencies() 
 
All tests pass apart from the ones mentioned in http://community.jboss.org/message/524862#524862 which I know how to fix if Ales agrees:
 
> mailto:kabir.khan at jboss.com wrote:
>  
> I mean this:
>  
> *public* *void* testPlainLifecycleDependencyWrongOrder() *throws* Throwable
>    {
>       plainLifecycleDependencyWrongOrder();
>  
>       ControllerContext context2 = assertInstall(1, "Name2", ControllerState.+CONFIGURED+);
>       ControllerContext context1 = assertInstall(0, "Name1");
> +assertEquals+(ControllerState.+INSTALLED+, context2.getState());
>  
> SimpleBeanWithLifecycle bean1 = (SimpleBeanWithLifecycle) context1.getTarget();
> +assertNotNull+(bean1);
>  
> SimpleBeanWithLifecycle bean2 = (SimpleBeanWithLifecycle) context2.getTarget();
> +assertNotNull+(bean2);
>  
> +assertEquals+(1, bean1.createOrder);
> +assertEquals+(2, bean2.createOrder);
> +assertEquals+(3, bean1.startOrder);
> +assertEquals+(4, bean2.startOrder);
>    }
>  
> The new resolver works with
> +assertEquals+(1, bean1.createOrder);
> +assertEquals+(2, bean1.startOrder);
> +assertEquals+(3, bean2.createOrder);
> +assertEquals+(4, bean2.startOrder);
>  
> The actual hardcoded orders of beans 1 and 2 is an implemetation detail as I see it. The real check is making sure that the initial install of context 2 does not go beyond CONFIGURED and:
> bean1.startOrder > bean1.createOrder
> bean2.startOrder > bean2.createOrder
> bean2.createOrder > bean1.createOrder
> bean2.startOrder > bean1.startOrder
>  
> I've got an infinite loop in the indexing resolver when I start up AS which I need to fix before I can get any measurements of boot time, although it sounds like we won't gain much from this.
>  

--------------------------------------------------------------

To reply to this message visit the message page: http://community.jboss.org/message/525047#525047




More information about the jboss-user mailing list