sorry about that Brian. No injustice intended.
Ben, I actually was wondering about the test case. I hardly see my own
application doing things this way but was trying to see where the achiles hill
was before I jump into adopting it.
YES, I'd like to get a better, complete, test case for benc
GC was suggested by Brian. :-)
Since the major cost of POJO cache (TreeCacheAop) is in putObject (it has to
map the object recursively into primitive fields), I'd say benchmark putObject
with different POJO every time is probably not a good idea. It is probably not
a good use case anyway.
Idea
Bela,
I use a different object every time. To ensure that object creation does not
factor into the benchmark, I create all the 1 objects before hand and
maintain in a array which I then pluck objects from and put into cache.
Ben,
I ran the gc stats and sure enough there are bunch of full G
I'd suggest REPL_ASYNC (not REPL_SYNC) and fc-fast-minimalthreads.xml from the
JGroups distro. That may make a diff if you replicate many modifications
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3910118#3910118
Reply to the post :
http://www.jboss.com/ind
When you run this it would also be good to create a garbage collection log
(-Xloggc:somefile). I'm wondering if your 1718ms result is due to a full gc.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3909933#3909933
Reply to the post :
http://www.jboss.com/ind
When you do putObject test, do you use the same POJO over and over again? If it
is, it should be (almost) an no-op underneath. So it should be very fast
actually.
-Ben
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3909929#3909929
Reply to the post :
http:
Can you create a JIRA issue and attach your test to it so we can take a look ?
This needs to be a self-sufficient test (no dependent libs), and please also
include the configuration used, and a description of how to run the test
View the original post :
http://www.jboss.com/index.html?module=bb&
forgive me, there might be persistance but what ever replSync-service.xml is
using for the PropagationManager example, is used in my bench mark.
The provided output shows the exact configuration.
Missed the hardware configs as well:
- Pentium 4
- Linux 2.6, Debian install
- 2 gig RAM (5400
I should also note:
the benchmark is simply using the same configuration as PropogationManager
example from Ben's article.
So there is no persistance,
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3909825#3909825
Reply to the post :
http://www.jboss.c
