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

Thomas Mueller commented on OAK-8673:
-------------------------------------

> we almost never benefit from the lazy permission evaluation (compared to 
> reading all permission entries right away). 

Just to make sure: It sounds like "lazy permission evaluation disabled" means 
"reading all permission entries right away"... right? And then it sounds like 
you consider disabling lazy permission evaluation?

Which benchmark results show data for "lazy permission evaluation disabled", 
and which results show results for "lazy permission evaluation enabled"? I only 
see different settings for 

* Items to Read
* Repeat Read
* Number of ACEs
* Number of Principals
* EagerCacheSize


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

Reply via email to