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] [Commented] (OAK-8673) Determine and possibly adjust size of eagerCacheSize
Date Fri, 01 Nov 2019 09:07:00 GMT

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

Angela Schreiber commented on OAK-8673:

[~thomasm], yes sort of.... except for the fact that there is currently no way to completely
disable the lazy-evaluation mechanism altogether.... the threshold to move from eagerly-loading
all permission entries to lazy loading is defined by the {{EagerCacheSize}}. that's why the
result contain series of increasing number of access control entries, number of principals
and cache-size.

i will take a closer look at the results from repeated-read again today and compare it to
the totally random reading as repeated-reading will benefit from the map in the {{DefaultPermissionCache}},
whereas totally random reading might in the worst case never hit that map (while always reading
from the cached entries as long as eager-cache-size is not reached.

> 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

View raw message