Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of anchela@adobe.com designates
 64.18.1.35 as permitted sender)
From: Angela Schreiber <anchela@adobe.com>
To: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org>
Date: Tue, 5 Nov 2013 07:36:22 +0000
Subject: Re: [oak] ACL cache performance
Thread-Topic: [oak] ACL cache performance
Thread-Index: Ac7Z+bhbGdjExcNqR4qZyMDke5I7ig==
Message-ID: <CE9E5ADD.C4CC%anchela@adobe.com>
In-Reply-To: 
 <CAB+dfi=Ac7LJWvFyrE_4V31k475jgciijm_mqUS1gcJZuxPiVQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.2.130206
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

hi

great... btw. i also added some improvement to the treepermission
implementation such that for unambiguous cases the read-permission
for properties present with a node is not evaluated individually.

this is currently very simple and i will try if improvements
allow further performance gain... e.g. if a node is not access controlled
at all the read status of the parent might be inherited right away.

for that matter i added another test
ConcurrentReadRandomNodeAndItsPropertiesTest
that doesn't randomly read items but rather reads random nodes
and subsequently it's properties... while reading *all* properties is
probably artificial, i assume that reading at least a couple of properties
for each node is very common (e.g. reading the sling:resourceType property,
reading the title of a page or reading the name of a user).

kind regards
angela


On 11/5/13 7:40 AM, "Tobias Bocanegra" <tripod@apache.org> wrote:

>Hi,
>
>I made some minor changes to cache handling, so that it only caches the
>everyone's entries. I also optimized the entry iterator slightly, so that
>it's even more lazy. together with the improvements of jukka the micro
>benchmarks look really good, at least for the ManyUserReadTest. If we also
>get rid of the SecurityContext, I expect even further improvements.
>
>Regards, Toby
>
>Benchmarks: ManyUserReadTest
>Fixtures: Oak-Tar Jackrabbit
>Runtime: 10
>Num Items: 10000
>Concurrency: 1,2,4,8,10,15,20,50
>Random User: true
>Profiling: false
>--------------------------------------
>Executing benchmarks as admin: false on Oak-Tar
>-----------------------------------------------------------
># ManyUserReadTest          ,      C,    min,    10%,    50%,    90%,
> max,      N
>Oak-Tar                     ,      1,    292,    302,    308,    316,
> 326,     33
>Oak-Tar                     ,      2,    322,    335,    343,    357,
> 365,     60
>Oak-Tar                     ,      4,    416,    453,    474,    501,
> 515,     87
>Oak-Tar                     ,      8,    699,    717,    746,    770,
> 800,    112
>Oak-Tar                     ,     10,    790,    889,    940,    991,
>1027,    110
>Oak-Tar                     ,     15,    711,   1315,   1428,   1518,
>1590,    111
>Oak-Tar                     ,     20,   1430,   1603,   1919,   2090,
>2240,    117
>Oak-Tar                     ,     50,   2519,   2997,   4640,   5632,
>6626,    127
>Executing benchmarks as admin: false on Jackrabbit
>-----------------------------------------------------------
># ManyUserReadTest          ,      C,    min,    10%,    50%,    90%,
> max,      N
>Jackrabbit                  ,      1,    328,    338,    347,    383,
> 705,     28
>Jackrabbit                  ,      2,    399,    404,    432,    647,
> 856,     44
>Jackrabbit                  ,      4,    528,    539,    565,    959,
> 979,     64
>Jackrabbit                  ,      8,   1106,   1130,   1166,   1514,
>1554,     72
>Jackrabbit                  ,     10,   1368,   1399,   1467,   1833,
>1886,     70
>Jackrabbit                  ,     15,   2016,   2137,   2259,   2617,
>2710,     75
>Jackrabbit                  ,     20,   1496,   1562,   3357,   3595,
>3729,     70
>Jackrabbit                  ,     50,   8222,   8563,   8814,   9022,
>9416,    100
>Executing benchmarks as admin: true on Oak-Tar
>-----------------------------------------------------------
># ManyUserReadTest          ,      C,    min,    10%,    50%,    90%,
> max,      N
>Oak-Tar                     ,      1,    127,    128,    132,    136,
> 140,     76
>Oak-Tar                     ,      2,    144,    148,    155,    160,
> 165,    130
>Oak-Tar                     ,      4,    188,    206,    217,    227,
> 243,    186
>Oak-Tar                     ,      8,    314,    343,    355,    367,
> 395,    231
>Oak-Tar                     ,     10,    289,    432,    462,    498,
> 534,    220
>Oak-Tar                     ,     15,    386,    624,    703,    785,
> 868,    219
>Oak-Tar                     ,     20,    535,    832,    948,   1125,
>1357,    215
>Oak-Tar                     ,     50,   1372,   1810,   2415,   3013,
>3692,    223
>Executing benchmarks as admin: true on Jackrabbit
>-----------------------------------------------------------
># ManyUserReadTest          ,      C,    min,    10%,    50%,    90%,
> max,      N
>Jackrabbit                  ,      1,    245,    247,    259,    300,
> 630,     37
>Jackrabbit                  ,      2,    296,    301,    310,    360,
> 631,     60
>Jackrabbit                  ,      4,    413,    428,    474,    711,
> 762,     80
>Jackrabbit                  ,      8,    465,    783,    872,   1137,
>1200,     89
>Jackrabbit                  ,     10,    927,    981,   1114,   1494,
>1599,     92
>Jackrabbit                  ,     15,   1328,   1446,   1710,   2210,
>2681,     90
>Jackrabbit                  ,     20,    914,   1787,   2327,   3238,
>3425,     88
>Jackrabbit                  ,     50,   1305,   1691,  10351,  10852,
> 11269,     61
>
>
>On Mon, Nov 4, 2013 at 2:01 AM, Tobias Bocanegra <tripod@apache.org>
>wrote:
>
>>
>>
>> On Monday, November 4, 2013, Angela Schreiber wrote:
>>
>>> hi
>>>
>>> thanks for the figures and the effort. btw... this discussion
>>> belong oak dev list and not to the adobe internal list -> moving.
>>>
>>> if the global cache doesn't add to much to the performance gain
>>> then i would suggest that we drop it immediately...
>>
>>
>> sure, I'll look at it again.
>>
>>
>>> in jackrabbit the
>>> caching on a global level was the most troublesome part of the
>>> whole permission evaluation and i would definitely want to
>>> avoid running into the same issues again.
>>>
>>> i would suggest to change this to an 'everyone' only cache as i
>>> proposed it earlier to you in a private discussion which also
>>> included a first draft of such an everyone-cache.
>>
>>
>> yes. although it should be a general cache that looks at the principals
>> that have a lot permission entries. this might be the everyone, but can
>> also be other ones.
>>
>> regards Toby
>>
>>>
>>> regards
>>> angela
>>>
>>> On 11/1/13 8:43 AM, "Tobias Bocanegra" <tripod@adobe.com> wrote:
>>>
>>> >Hi,
>>> >
>>> >I quickly tested the ACL performance again using the ManyUserReadTest.
>>> >The tests consists of reading 10k items from a 120k item repository
>>> >which has an ACL set on every 10th node. Each tests uses a different
>>> >user (1 of 1000) which each is member of 10 groups.
>>> >
>>> >if my tests are accurate, oak shows now the same performance as
>>> >jackrabbit. for admin sessions, it's even faster than jackrabbit. I
>>> >find it still not acceptable, that the non-admin case is 3 times
>>> >slower than the admin case.
>>> >
>>> >it's also of significance, that the global cache does not really gain
>>> >much performance for this test. see the last section of numbers. I
>>> >think that the global ACL cache is only beneficial for some
>>> >principals, like "everyone" that are used for every request. and/or
>>> >only really makes a difference, if the overall ACL evaluation overhead
>>> >is reduced.
>>> >
>>> >Regards, Toby
>>> >
>>> >Executing benchmarks as admin: false on Oak-Tar
>>> >-----------------------------------------------------------
>>> ># ManyUserReadTest          ,      C,    min,    10%,    50%,    90%,
>>> >  max,      N
>>> >Oak-Tar                     ,      1,    565,    578,    600,    615,
>>> >  627,     34
>>> >Oak-Tar                     ,      2,    653,    681,    715,    761,
>>> >  798,     56
>>> >Oak-Tar                     ,      4,    822,    989,   1053,   1101,
>>> > 1126,     78
>>> >Oak-Tar                     ,      8,   1509,   1626,   1722,   1798,
>>> > 1893,     96
>>> >Oak-Tar                     ,     10,   1905,   2041,   2175,   2298,
>>> > 2375,    100
>>> >Oak-Tar                     ,     15,   2545,   2850,   3201,   3484,
>>> > 3663,    103
>>> >Oak-Tar                     ,     20,   3519,   3852,   4254,   4737,
>>> > 5251,    100
>>> >Oak-Tar                     ,     50,   2666,   9504,  10450,  11440,
>>> >13050,    104
>>> >Executing benchmarks as admin: false on Jackrabbit
>>> >-----------------------------------------------------------
>>> ># ManyUserReadTest          ,      C,    min,    10%,    50%,    90%,
>>> >  max,      N
>>> >Jackrabbit                  ,      1,    455,    495,    539,    625,
>>> > 1148,     36
>>> >Jackrabbit                  ,      2,    507,    512,    575,    841,
>>> > 1264,     62
>>> >Jackrabbit                  ,      4,    768,    789,    861,   1220,
>>> > 1266,     88
>>> >Jackrabbit                  ,      8,   1416,   1516,   1624,   1999,
>>> > 2038,     96
>>> >Jackrabbit                  ,     10,   1764,   1812,   2074,   2796,
>>> > 2859,     90
>>> >Jackrabbit                  ,     15,   3030,   3077,   3611,   3841,
>>> > 3950,     90
>>> >Jackrabbit                  ,     20,   4495,   4683,   4874,   5031,
>>> > 5121,    100
>>> >Jackrabbit                  ,     50,  12219,  12546,  12827,  13232,
>>>
>>