jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Angela Schreiber (Jira)" <j...@apache.org>
Subject [jira] [Comment Edited] (OAK-8673) Determine and possibly adjust size of eagerCacheSize
Date Thu, 31 Oct 2019 16:19:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-8673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16964106#comment-16964106
] 

Angela Schreiber edited comment on OAK-8673 at 10/31/19 4:18 PM:
-----------------------------------------------------------------

[~thomasm], [~fabrizio.fortino@gmail.com], as just discussed in the office, I would very much
appreciate if you had a bit of time to look at the results and the {{EagerCacheSizeTest}}
and my intermediate summary above. I verified that there is really a new test-session created
for each test-run in order to make sure there is a {{PathEntryMapCache}} computed every time
(if the cache size is not exceeded). as soon as the cache-size is exceeded the evaluation
will fall back to {{DefaultPermissionCache}}, which will load permission entries as they are
needed. the read-only nature of the benchmark asserts that we don't hit the cache-reset.

if you feel you first need to get some understanding of the underlying feature, you can start
from {{PermissionProviderImpl}} to get the bigger picture or directly start at {{PermissionCacheBuilder}}.


was (Author: anchela):
[~thomasm], [~fabrizio.fortino@gmail.com], as just discussed in the office, I would very much
appreciate if you had a bit of time to look at the results and the {{EagerCacheSizeTest}}.
I verified that there is really a new test-session created for each test-run in order to make
sure there is a {{PathEntryMapCache}} computed every time (if the cache size is not exceeded).
as soon as the cache-size is exceeded the evaluation will fall back to {{DefaultPermissionCache}},
which will load permission entries as they are needed. the read-only nature of the benchmark
asserts that we don't hit the cache-reset.

if you feel you first need to get some understanding of the underlying feature, you can start
from {{PermissionProviderImpl}} to get the bigger picture or directly start at {{PermissionCacheBuilder}}.

> Determine and possibly adjust size of eagerCacheSize
> ----------------------------------------------------
>
>                 Key: OAK-8673
>                 URL: https://issues.apache.org/jira/browse/OAK-8673
>             Project: Jackrabbit Oak
>          Issue Type: Technical task
>          Components: core, security
>            Reporter: Angela Schreiber
>            Assignee: Angela Schreiber
>            Priority: Major
>
> The initial results of the {{EagerCacheSizeTest}} seem to indicate that we almost never
benefit from the lazy permission evaluation (compared to reading all permission entries right
away). From my understanding of the results the only exception are those cases where only
very few items are being accessed (e.g. reading 100 items).
> However, I am not totally sure if this is not a artifact of the random-read. I therefore
started extending the benchmark with an option to re-read a randomly picked item more that
once, which according to some analysis done quite some time ago is a common scenario specially
when using Oak in combination with Apache Sling.
> Result are attached to OAK-8662 (possibly more to come).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message