On 9/21/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi,On 9/20/06, Jukka Zitting <[EMAIL PROTECTED]> wrote: > Another possible measure is of course count the total number of > property reads within a given timeframe given any number of concurrent > threads. That number should go up when the first few threads threads > are added since the I/O waits can be used to process other threads, > but then start slowly declining due to the context switching and other > thread overhead. I'll actually run a test like that, stay tuned for > the results... OK, here are the results for running the following code snippet over and over again with a different numbers of concurrent threads: int i = (int) (Math.random() * 100); int j = (int) (Math.random() * 100); Node node = root.getNode("test" + i + "/test" + j); node.getProperty("test").getString(); The results by the number of concurrent threads are listed below. The reported time is the number of *microseconds* taken by the average execution of the above code. Threads Time 1 58 ************ 2 50 ********** 3 63 ************* 4 63 ************* 5 70 ************** 6 71 ************** 7 69 ************** 8 68 ************** 9 78 **************** 10 86 ***************** --------- 20 118 ************************ 30 113 *********************** 40 123 ************************* 50 129 ************************** 60 135 *************************** 70 142 **************************** 80 146 ***************************** 90 141 **************************** 100 156 ******************************* As expected the number show an improvement when adding a second thread, but already the third thread starts the slow decrease in performance. The decrease is noticeably higher than just the threading overhead, but the performance still quite reasonable, the average execution time at 100 concurrent threads is just 2.5 times the execution time at a single thread.
Jukka I am not sure how you have computed with such accuracy. Also, I am thinking that the more times you are running that look the bigger the chances are to reread the same property and so to hit the cached node in the session (and this results in a massive improvement of the performance). Am I wrong? ./alex -- .w( the_mindstorm )p.
BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
