Hello,
ConnectSelectionKeyOP and SelectionKeyOP are cached.
These objects are very light.
About equal to the wrapper concurrentlinkedqueue creates to do the caching.
In concurrent situations, just keeping a few or even many normal references
in a "struct" that must be cleared in a recycle method can never be a win.
Not that it changes the results for caching of simple objects but:
I will further improve my testing code by ensuring that the test operation
is happening in
a spread out manner, so threads even if doing something else 90% of the
time dont hit the CLQ
at same time anyhow etc.
That is the true killer for CLQ , if many threads accesses it at the same
time.
so i need to avoid that inorder to get favorable/realistic values for CLQ.
2009/1/7 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>
> 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?
>
> 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
>
>
--
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.