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

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

[~angela] I'm sorry I don't fully understand this... Is there some 
documentation where this is explained? It might help to have it, for cases were 
the cache sizes need to be adjusted (to avoid out of memory). As far as I know 
(maybe wrong), there is:

* eager cache (per session? in number of entries and not memory usage. 
configurable as you configured it, but how?)
* lazy-evaluation cache (per session? how large? I assume in number of entries 
and not memory usage. configurable?)
* defaultpermissioncache (what is that exactly? is it lazy-evaluation cache or 
eager cache or something else?)

When opening a session, the eager cache is filled if cache size is large 
enough(?) If too large, then not. But there is a lazy-evaluation. What I still 
don't get - If benchmark results are if the eager cache is disabled, why is it 
so slow? Is it just that for this test case, hit rate on the lazy-evaluation 
cache is so bad?

> 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