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.82.237 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:references;
        b=mIr9WHpW9kil/ftrn0KQVNBcqHZ2DO7XGoM+8EVPFOAcJ5T4MoV+wk8drp3Kjx6k8FL/EO43qxtGtmgYg5eqVvtu2git3VFZ+JaRQf8179y2ePES7m5DHQa5gkwOXSpWXtCrpnIRw+ucvf5M09YtVIscI+NLTYcEoXHVlyyY2c4=
Message-ID: <510143ac0609211557u6c9baffj1260ca6e4c286def@mail.gmail.com>
Date: Fri, 22 Sep 2006 01:57:15 +0300
From: "Jukka Zitting" <jukka.zitting@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: Working with JCR in highly concurrent applications
In-Reply-To: <c6f400460609201534n5db13a8v416156fde9e96a2d@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_Part_18616_23610300.1158879435431"
References: <c6f400460609200245u511e55b8he7e4edf04620367c@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>
	 <c6f400460609201534n5db13a8v416156fde9e96a2d@mail.gmail.com>

------=_Part_18616_23610300.1158879435431
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

On 9/21/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
> Jukka I am not sure how you have computed with such accuracy.

The raw results are shown below. The test case (attached) consists of
running a given number of parallel threads that each just repeat the
code snippet that reads a single property from a random location. The
first column reports the number of concurrent threads in a test run,
the second column the total number of property reads performed, and
the third column the exact measurement time (in milliseconds). The
test setup allowed the threads to run for five seconds before starting
the measurements. The measurement lasted about 30 seconds (the exaxt
time was measured), and the threads only finished running after the
measurement period had ended.

Threads,Count,Time
1,515263,30000
2,602342,30047
3,480340,30063
4,476496,30203
5,433930,30188
6,428222,30219
7,437373,30000
8,515249,34781
9,384501,30000
10,349670,30000
20,254787,30000
30,266225,30000
40,243408,30000
50,233156,30000
60,222628,30000
70,211203,30000
80,216089,31468
90,212402,30000
100,196199,30563

The average times per single execution of the code snippet were
calculated directly from the above data.

> 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?

You're right! I didn't take into account the caching improvements
during the summer (JCR-471), only figuring that a content structure of
10k nodes will outweight the default 1k size of the previous item
state cache. So consider the above results representative of
Jackrabbit when the working set is fully cached.

To decrease the cache effect I increased the size of the content model
from 10k nodes to 40k and 90k nodes by using 200x200 and 300x300
content structures instead of the original 100x100 structure. The
results are below, again in microseconds:

Threads  with 40k nodes       with 90k nodes
-----------------------------------------------------------------------
      1  1336 *************   3199 ********************************
      2  1190 ************    2520 *************************
      3  1177 ************    2300 ***********************
      4  1152 ************    2200 **********************
      5  1182 ************    2104 *********************
      6  1161 ************    2001 ********************
      7  1122 ***********     1987 ********************
      8  1106 ***********     1867 *******************
      9  1110 ************    1829 ******************
    ---
     10  1088 ***********     1810 ******************
     20  1143 ***********     1805 ******************
     30  1135 ***********     1701 *****************
     40  1173 ************    1582 ****************
     50  1131 ***********     1545 ***************
     60  1173 ************    1549 ***************
     70  1238 ************    1517 ***************
     80  1171 ************    1580 ****************
     90  1174 ************    1555 ****************
    100  1065 ***********     1540 ***************

With these larger working sets, the random property access code
snippet executes at 1+ milliseconds and doesn't grow by the number of
concurrent threads.

BR,

Jukka Zitting

-- 
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development

------=_Part_18616_23610300.1158879435431--