cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Results of new ContainerManager abstraction (now that it is working)
Date Mon, 18 Feb 2002 20:08:14 GMT
Gerhard Froehlich wrote:
> Berin,
> 
> 
>>The ExcaliburComponentManager is much slower, and will be the result of most scalability
>>issues in Cocoon.  The ContainerManager starts faster, and runs faster--even though
it
>>does more work (with all the helper managers).  The only area where ContainerManager
is
>>slower is on shutdown, although it is not that much slower.  There is one more optimization
>>that will assist on ContainerManager's init time (currently pools are initialized
in the
>>constructor--that will be moved to the initialize() method).
>>
>>
>>    [junit] Running org.apache.avalon.excalibur.system.test.ContainerProfile
>>    [junit] DEBUG   10140   [        ] (): added new LogTargetFactory of type file
>>    [junit] DEBUG   10140   [        ] (): added new LogTarget of id root
>>    [junit] DEBUG   10140   [        ] (): added logger for category test.test
>>    [junit] INFO    10140   [test    ] (): Test Case: ECM_ContainerManager_StartTime
>>    [junit] INFO    10140   [test    ] ():      ECM time = 2494ms.
>>    [junit] INFO    10140   [test    ] ():      ContainerManager time = 1242ms.
>>    [junit] INFO    10140   [test    ] ():   => ContainerManager is 2.0 X as fast
as 
>>ExcaliburComponentManager on init.
>>    [junit] INFO    10140   [test    ] ():   => ExcaliburComponentManager is 0.49
X as 
>>fast as ContainerManager on init.
>>    [junit] INFO    10140   [test    ] (): Test Case: Test Case: ECM_ContainerManager_UseageTime
>>    [junit] INFO    10140   [test    ] ():      
>>AbstractContainer$ContainerComponentManager time = 2293ms. to use 50000 calls on 3

>>components.
>>    [junit] INFO    10140   [test    ] ():      ExcaliburComponentManager time = 
>>212596ms. to use 50000 calls on 3 components.
>>    [junit] INFO    10140   [test    ] ():   => 
>>AbstractContainer$ContainerComponentManager is 92.71 X as fast as 
>>ExcaliburComponentManager.
>>    [junit] INFO    10140   [test    ] ():   => ExcaliburComponentManager is 0.01
X as fast as 
>>AbstractContainer$ContainerComponentManager.
>>    [junit] INFO    10140   [test    ] (): Test Case: ECM_ContainerManager_KillTime
>>    [junit] INFO    10140   [test    ] ():      ECM time = 10ms.
>>    [junit] INFO    10140   [test    ] ():      ContainerManager time = 551ms.
>>    [junit] INFO    10140   [test    ] ():   => ContainerManager is 0.01 X as fast
as 
>>ExcaliburComponentManager on dispose.
>>    [junit] INFO    10140   [test    ] ():   => ExcaliburComponentManager is 55.1
X as 
>>fast as ContainerManager on dispose.
>>    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 222.991 sec
>>-- 
>>
> 
> This makes hope ;). How is the BucketMap?


These results are using the BucketMap for both ECM and the ContainerManager.  I did find that
I needed to change the default size of the BucketMap (i.e. 255 instead of 256 buckets).
The reason is that the default hashCode() algorithm for an Object is it's address--which typically
is a number that is evenly divisible by any power of 2 (2^8 == 256).  This weights the buckets
for 0, 64, and 128 rather heavily (mostly 0).  I provided a test in the constructor
to ensure that the number of buckets is at least 17, and not a power of 2.

The ECM has alot of overhead--some of which is due to the fact that all Components directly
reference the exact same instance of ExcaliburComponentManager.  Therefore there is a longer
wait
for the releasing of Components.  There is also more processing in each lookup.

The ContainerManager approach instantiates a new ComponentManager for each Component which
merely forwards requests to the ContainerManager.  That means that each Component has its
own
map for object to handler ( in the case that you have different configurations for the same
implementations).  The overall solution provides less concurrency problems, and the resource
management is pretty good too.

Keep in mind that the ContainerManager also uses the new excalibur.mpool (aka managed pool)
package which has been shown to be even more efficient than Leif's ResourceLimitingPool. 
The
combination of asynchronous management and more efficient implementations make the ECM feel
old
and archaic.


The proof is in the pudding.  Using 100 threads to request 3 objects 50,000 times respectively
is more of a harsh microbenchmark.  However, it is plain to see that the ContainerManager
kicks
the ECM but on regular usage.  Depending on the load of my machine when I run the benchmarks
the
difference in speed is a low as 70:1 and as high as 93:1.  Those numbers speak for themselves.




-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message