jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Working with JCR in highly concurrent applications
Date Wed, 20 Sep 2006 21:41:23 GMT
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