On 9/20/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote:
On 9/20/06, Jukka Zitting <[EMAIL PROTECTED]> wrote: > Hi, > > On 9/20/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote: > > I will try to trim down my functional test. Still, I am missing the > > repository creation/load fixture, so I will highly appreciate if you > > can share this one (and I don't have to write it my own :-( ). > > You can check my simple test case at > http://people.apache.org/~jukka/2006/ConcurrentTest.java. You can > compile and run it as follows if you have Jackrabbit core and all the > dependencies in your classpath. > > $ javac ConcurrentTest.java > $ java ConcurrentTest > > The test sets up a simple content structure of about 10k nodes, each > containing a single "test" property. The test threads count the wall > clock time it takes the "test" property of a thousand randomly > selected nodes. Special staging is used to ensure that the test > results are not affected by the startup or shutdown periods of the > threads. I figure a test framework like TestNG would take care of all > that automatically... > > Below is a verbatim copy of the output of a representative test run on > my laptop (Windows XP, Java 1.4, Pentium M 750, 1,86 GHz, 1GB DDR2 > 533MHz RAM, 2x100GB SATA 5400rpm HDD): > > Threads,Count,Min,Sum,Max > 10,235,765,294828,3984 > 20,218,2109,619515,4765 > 30,185,3750,848800,6000 > 40,200,5015,1251299,7500 > 50,199,5969,1658329,10296 > 60,182,5828,1826373,11234 > 70,158,7782,1810896,12468 > 80,160,9015,2185606,14469 > 90,179,8563,2766261,16594 > 100,105,10672,1891184,18750 > > See http://people.apache.org/~jukka/2006/concurrent.png for a graph on > how the minimum, average, and maximum wall clock time for reading 1000 > properties grows by the number of concurrent threads. At least these > results are very linear as expected. >Weird, but after everything here is what I am seeing (with jackrabbit 1.0): Exception in thread "main" javax.jcr.ItemNotFoundException: cafebabe-cafe-babe-cafe-babecafebabe at org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.java:464) at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:320) at org.apache.jackrabbit.core.ItemImpl.restoreTransientItems(ItemImpl.java:708) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1208) at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:805) at org.noco.jackrabbit.perf.ConcurrentTest.main(ConcurrentTest.java:125)
I think this was caused by an OutOfMemory exception. By configuring the JVM to use 256M it seems I am getting some similar results. But my question is: why is this happening (and why would it be normal)? ./alex -- .w( the_mindstorm )p.
./alex -- .w( the_mindstorm )p. > BR, > > Jukka Zitting > > -- > Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] > Software craftsmanship, JCR consulting, and Java development >
