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