jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-2843) Broadcasting cache
Date Wed, 02 Dec 2015 11:45:11 GMT

    [ 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):
persistentCache="crx-quickstart/repository/cache,size\=1024,binary\=0,broadcast\=tcp:key 123"
* 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 
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

View raw message