[jira] [Commented] (OAK-2843) Broadcasting cache

["Thomas Mueller (JIRA)" <ji...@apache.org>]

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

Thomas Mueller commented on OAK-2843:
-------------------------------------

I could now verify the cache works as expected. My test was: 

* Two cluster nodes, using the MongoDB document store.
* Delete the persistent cache files.
* Using the persistent cache setting is follows (OSGi configuration):
{noformat}
persistentCache="crx-quickstart/repository/cache,size\=1024,binary\=0,broadcast\=tcp:key 123"
{noformat}
* Read all nodes of the repository (called "traversal check" in our application).
* This took 20 seconds (because it had to load all nodes from MongoDB).
* Do the same on the other cluster node, which only took 5 seconds.

I ran the same test without the broadcasting cache enabled, that is just with 
{noformat}
persistentCache="crx-quickstart/repository/cache,size\=1024,binary\=0"
{noformat}
The first time it took 24 seconds on _each_ cluster node (because both cluster nodes have to load all data from MongoDB, if the persistent cache is empty). The second time it took 5 seconds. After a restart (but without deleting the local persistent cache), it also took 5 seconds.

> Broadcasting cache
> ------------------
>
>                 Key: OAK-2843
>                 URL: https://issues.apache.org/jira/browse/OAK-2843
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: mongomk
>            Reporter: Thomas Mueller
>            Assignee: Thomas Mueller
>             Fix For: 1.3.12
>
>
> In a cluster environment, we could speed up reading if the cache(s) broadcast data to other instances. This would avoid bottlenecks at the storage layer (MongoDB, RDBMs).
> The configuration metadata (IP addresses and ports of where to send data to, a unique identifier of the repository and the cluster nodes, possibly encryption key) rarely changes and can be stored in the same place as we store cluster metadata (cluster info collection). That way, in many cases no manual configuration is needed. We could use TCP/IP and / or UDP.



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