jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <tri...@apache.org>
Subject Re: [oak] ACL cache performance
Date Mon, 04 Nov 2013 10:01:29 GMT
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,
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message