[jboss-user] [JBossCache] - Re: Reading threads are blocked
FredrikJ
do-not-reply at jboss.com
Thu Jul 12 07:09:37 EDT 2007
Using the testbeds from above on CR3 shows a significant improvement over CR2. The source for the tests can be found here: http://www.robotsociety.com/cache/cr3/src.rar
NB: These tests are micro-benchmarks, i.e. not a real-life scenario.
Parallel tests
Reading threads access all available nodes concurrently. Reading throughput was improved by 27%. All threads are still mostly blocked. I'm not sure how much concurrency we can claim here.
Threads: http://www.robotsociety.com/cache/cr3/parallell_threads.GIF
Dedicated tests
Four threads all read from a dedicated node. There is one node per thread so they should never try to read from the same node. Reading throughput was improved by 40%. Thread concurrency is clearly improved which can be seen in the profiler as well.
Threads comparison: http://www.robotsociety.com/cache/cr3/comparison.GIF
It seems that in the parallel scenario, most threads are blocked by the initLock in UnversionedNode. The lock is lazily initiated in case we don't need locking, but on the other hand you then force a synchronized upon every threads that wants to get the lock reference. The synchronization is only to check if the lock has been initialized and when it has it really serves no purpose, so arguably this could be solved without having to synchronize on every getLock() call. However, using non-lazy initialization and removing the sync block did not result in any significantly higher concurrency since the next mutex is in the tryLock on the lock that we pass back.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063426#4063426
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063426
More information about the jboss-user
mailing list