Salut,
Oleksiy Stashok wrote:
> Very good investigation, Gustav!
>
> I think we have to make similar ones on grizzly-framework level to check
> reasonability of having caches for different objects like Context and
> other.
> Can you pls. share the testing code or probably we can have this as
> utility class within framework or http-utils module.
>
> BTW, Jeanfrancois, may be it makes sense to rename http-utils to utils
> or give to this module some other general name, cause currently it has
> all Grizzly utility classes?
It will breaks all our users build if we do that. Should we advertise
first (blog) then make the change? I'm +1 for it, but I'm just
unconfortable to break the community :-)
A+
-- jeanfrancois
>
> Thanks.
>
> WBR,
> Alexey.
>
> On Dec 30, 2008, at 20:49 , gustav trede wrote:
>
>> Salut,
>>
>> I have spent entire day comparing caching of CometTask , CometContext
>> with non caching.
>> using 1 to 64 threads that 'allocate' in pure such loops and other
>> tests with heavy logic run inbetween the allocations,
>> also tests with storing the comettasks in global datastructures that
>> is sometimes cleared etc.
>>
>> running single tests for hours to ensure the GC is long term stressed
>> and results are consistent with shorter runs.
>>
>> using jdk 1.6u12 and 1.7b42 64bit . cpu is a dualcore , intel E8600.
>> -server -XX:+UseParallelOldGC -XX:+UseParallelGC -Xms256m -Xmx256m
>> -XX:NewRatio=2 with and without -XX:+AggressiveOpts
>>
>>
>> for CometContext, the caching is a win for the most cases but
>> sometimes a draw.
>> due to its several ConcurrentHashMap that are extremely expensive to
>> create its in general good to cache it.
>>
>> CometTask caching is allways a loss, if measuring pure 'allocation', a
>> factor of 3+ on my system for 2-32 Threads.
>>
>> its natural that the caching is a loss for "basic" objects,
>> we have no String creation here, UTF8 strings are very expensive for
>> example.
>>
>> due to the caching itself in a ConcurrentLinkedQueue creates GC with
>> its wrapper object,
>> the cost for that is not so different from the object we are to cache,
>> add do that the concurrent mechanism overhead.
>>
>>
>> attached is the testcode. doing minor logic inbetween allocs.
>> output on my comp for the code in its current config :
>>
>> recycled = false allocator threads = 1 throughput = 17.8 Million
>> CometTasks/sec
>> recycled = false allocator threads = 4 throughput = 18.1 Million
>> CometTasks/sec
>> recycled = false allocator threads = 8 throughput = 18.6 Million
>> CometTasks/sec
>> recycled = false allocator threads = 32 throughput = 18.6 Million
>> CometTasks/sec
>> recycled = true allocator threads = 1 throughput = 7.4 Million
>> CometTasks/sec
>> recycled = true allocator threads = 4 throughput = 5.5 Million
>> CometTasks/sec
>> recycled = true allocator threads = 8 throughput = 5.5 Million
>> CometTasks/sec
>> recycled = true allocator threads = 32 throughput = 5.9 Million
>> CometTasks/sec
>> completed in 157 seconds.
>>
>> here with heavy work being done inbetween allocs:
>>
>> recycled = false allocator threads = 1 throughput = 1.7 Million
>> CometTasks/sec
>> recycled = false allocator threads = 4 throughput = 3.3 Million
>> CometTasks/sec
>> recycled = false allocator threads = 8 throughput = 3.3 Million
>> CometTasks/sec
>> recycled = false allocator threads = 32 throughput = 3.5 Million
>> CometTasks/sec
>> recycled = true allocator threads = 1 throughput = 1.3 Million
>> CometTasks/sec
>> recycled = true allocator threads = 4 throughput = 2.0 Million
>> CometTasks/sec
>> recycled = true allocator threads = 8 throughput = 1.9 Million
>> CometTasks/sec
>> recycled = true allocator threads = 32 throughput = 2.4 Million
>> CometTasks/sec
>> completed in 169 seconds.
>>
>>
>> --
>> your servant
>> gustav trede
>>
>> coding is art - not only something that bring food on the table,
>> everybody should be able to feel proud about their code,
>> that they have performed their best considering the given conditions.
>>
>> <Main.java>---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>