jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu" <the.mindstorm.mailingl...@gmail.com>
Subject Re: Working with JCR in highly concurrent applications
Date Wed, 20 Sep 2006 22:34:17 GMT
On 9/21/06, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On 9/20/06, Jukka Zitting <jukka.zitting@gmail.com> 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/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>

Mime
View raw message