[jira] [Resolved] (JCR-2442) make internal item cache hierarchy-aware

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

     [ https://issues.apache.org/jira/browse/JCR-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Dürig resolved JCR-2442.
--------------------------------
    Resolution: Later

> make internal item cache hierarchy-aware
> ----------------------------------------
>
>                 Key: JCR-2442
>                 URL: https://issues.apache.org/jira/browse/JCR-2442
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-jcr2spi
>            Reporter: Stefan Guggisberg
>            Assignee: Michael Dürig
>         Attachments: JCR-2442.patch
>
>
> currently there are 2 configuration parameters which affect the performance of client-sided tree traversals:
> - fetch-depth
> - size of item cache
> my goal is to minimize the number of server-roundtrips triggered by traversing the node hierarchy on the client.
> the current eviction policy doesn't seem to be ideal for this use case. in the case of relatively deep tree structures
> a request for e.g. '/foo' can easily cause a cache overflow and root nodes might get evicted from the cache.
> a following request to '/foo' cannot be served from cache but will trigger yet another deep fetch, despite the fact
> that the major part of the tree structure is still in the cache.
> increasing the cache size OTOH bears the risk of OOM errors since the memory footprint of the cached state seems 
> to be quite large. i tried several combinations of fetch depth and cache size, to no avail. i either ran into OOM errors 
> or performance was inacceptably slow due to an excessive number of server roundtrips.
> i further noticed that sync'ing existing cached state with the results of a deep fetch is rather slow, e.g.
> an inital request to '/foo' returns 11k items. the cache size is 10k, i.e. the cache cannot accomodate the entire 
> result set.  assuming that /foo has been evicted, the following request to '/foo' will trigger another deep 
> fetch which this time takes considerably moe time since the result set needs to be sync'ed with existing cached
> state. 
> using a LRU eviction policy and touching every node along the parent hierarchy when requesting an item might be a solution.



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