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 Thu, 21 Sep 2006 16:57:46 GMT
There is still some not yet answered question about JCR Session usage:
can it be used as a long-live object and shared between different
threads? Is it dangerous to do so?

./alex
--
.w( the_mindstorm )p.


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.
>
> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>

Mime
View raw message