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

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

[~thomasm], we had A in jackrabbit 1 and it was quite a terrible idea. 
regarding B: we can look at this. but as a matter of fact the permissions are 
slightly different to indices and other types of 'caches' as the number of 
permissions is for the vast majority of use cases limited... in either way, 
both topics essentially are beyond the task at hand to re-evaluate if the 
current value of eager-cache-size is sufficient or should be adjusted. i would 
therefore prefer to cover them with separate issues. also note: even for the 
lazy-evaluation a cache is populated (in fact there are even 2 maps in that 
case), so depending on the distribution of permission entries and the access 
pattern (read/writing), the lazy cache might even consume more memory than the 
eager-cache.... i will come up with some numbers to illustrate this.

> 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.
> Benchmarks with 10-times re-reading the same random item:
> As I would have expected it seems that the negative impact of lazy-loading is 
> somewhat reduced, as the re-reading will hit the cache populated while 
> reading.
> 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