Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (idunn.apache.osuosl.org: domain gmail.com designates
 66.249.92.170 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=fimNjt6lOqqpnwLkXSJvVQMiJaxhbZ8ZY3hcHvfCjXi1Uie13sfAncr1C39UgZO9hf1D5IsEnQOejSiOhz2aGQJcd13dEOszRsdrMZjT1eo603BOL5wLVaqK3CRiVczXMk1Tfo7I1flPSN8IF4iZi3x4oF3m/7wDXkL+RAT1zdQ=
Message-ID: <c6f400460609210957tfb05ff0u405b6858fb00a17c@mail.gmail.com>
Date: Thu, 21 Sep 2006 19:57:46 +0300
From: "Alexandru Popescu" <the.mindstorm.mailinglist@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: Working with JCR in highly concurrent applications
In-Reply-To: <510143ac0609201441t3d3c9809v8686e14ff8dfbf86@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <c6f400460609200245u511e55b8he7e4edf04620367c@mail.gmail.com>
	 <510143ac0609200912m4e5dddcbm423a22e272b2e227@mail.gmail.com>
	 <c6f400460609200920i60b8f21fjd67f229ad27d0d16@mail.gmail.com>
	 <510143ac0609201036l1293d5c1w4ad4608e3232804d@mail.gmail.com>
	 <c6f400460609201107y6f0429c0if198ac6a661fd815@mail.gmail.com>
	 <c6f400460609201131h64183e85s1be4a4f7c35024fa@mail.gmail.com>
	 <510143ac0609201203y41a17d3fje9d24cb24ffd616b@mail.gmail.com>
	 <c6f400460609201211s405a7cc6j576855fa6a8bec60@mail.gmail.com>
	 <510143ac0609201256h5bfbb875v6b199cdb9892f59f@mail.gmail.com>
	 <510143ac0609201441t3d3c9809v8686e14ff8dfbf86@mail.gmail.com>

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
>