[jira] [Commented] (OAK-5042) Improve caching of segments

["Michael Dürig (JIRA)" <ji...@apache.org>]

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

Michael Dürig commented on OAK-5042:
------------------------------------

!https://issues.apache.org/jira/secure/attachment/12836760/OAK-5042.png.png|width=500!

Graphs showing the quantiles of the number of times individual segments are loaded for various caching strategies/tweaks:
* [base|https://github.com/mduerig/jackrabbit-oak/tree/OAK-5042-base]; Base line with the standard Guava cache
* [nobin|https://github.com/mduerig/jackrabbit-oak/tree/OAK-5042-nobinary]: Same as 'base' but without caching bulk segments 
* [sample|https://github.com/mduerig/jackrabbit-oak/tree/OAK-5042-sample]: Same as 'base' but directing every 65536-th read of a segment into the cache instead of serving it directly from the memoised segment field ({{SegmentId.segment}})
* [cache|https://github.com/mduerig/jackrabbit-oak/tree/OAK-5042-cache]: Revert to LRU style cache similar to what we had pre OAK-3055 but with a lock free implementation
* [cache2| https://github.com/mduerig/jackrabbit-oak/tree/OAK-5042-cache2]: Same as 'cache' but recording access counts on the segment ids instead of the segments. This allows for tracking the access counts across evictions.

There is no much difference between 'base', 'nobin' an 'sample'. So no long hanging fruits there.
The pre OAK-3055 caching strategies are significantly more effective when it comes to evictions. This would suggest to switch back to such a strategy. However  there is still a few things left to do here:
* Why is 'cache2' worse than 'cache'? I would it expect to actually be better as it has more information on actual segment accesses. Is this a test artefact? A bug? Or is this hypothesis wrong?
* Move the actual cache into its own class and harden it for production (unit tests, double check correctness re. concurrency, implement monitoring and configurability). 



> Improve caching of segments
> ---------------------------
>
>                 Key: OAK-5042
>                 URL: https://issues.apache.org/jira/browse/OAK-5042
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: segment-tar
>            Reporter: Michael Dürig
>            Assignee: Michael Dürig
>              Labels: performance
>             Fix For: 1.5.13
>
>         Attachments: OAK-5042.png
>
>
> Various aspects of how Segment Tar caches segments could possibly improved. The current cache is a result of replacing the former ad-hoc cache with a proper one in OAK-3055. While the former was prone to contention under concurrent load the current cache is too oblivious about reads: read accesses are always served through {{SegmentId.segment}} and never actually hit the cache. This results in frequently accessed segments not to be seen as such by the cache and potentially being prematurely evicted. 
> Possibly approaches to address this problem include: 
> * Reinstantiating the cache we had pre OAK-3055 but making in fully concurrent. 
> * Convey the information about read accesses to the current cache. 
> * In either of the above cases avoid bulk segments from being placed into the cache. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)