[
https://issues.apache.org/jira/browse/OAK-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-5042.
--------------------------------
Resolution: Won't Fix
Fix Version/s: (was: 1.7.1)
(was: 1.8)
After further consideration and tests I couldn't find conclusive evidence for
changing the underlying cache: while some low level probing showed improvements
in the cache hit rate it also showed negative impacts elsewhere. I suggest to
take this issue up again should we encounter a specific bottleneck with the
segment cache which we have a benchmark for we can optimise against.
> 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, scalability
> 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.15#6346)
