[jira] [Commented] (OAK-8673) Determine and possibly adjust size of eagerCacheSize

["Angela Schreiber (Jira)" <ji...@apache.org>]

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

Angela Schreiber commented on OAK-8673:
---------------------------------------

[~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)