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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
