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

Julian Sedding updated OAK-2829:
--------------------------------
    Attachment: CompareAgainstBaseStateTest.java

A few weeks ago, while testing the migration of a CRX repository to a local 
MongoDB, I made some observations that may be related.

I was working with a modified version of oak-upgrade that allows incremental 
(or repeated) copying of a JR2 repo into an Oak repo. During the second run, 
with an identical source repo, I noticed that a lot of time was spent in the 
commit hooks calculating diffs.

In DocumentNodeState#compareAgainstBaseState(), I experimentally skipped the 
optimization for DocumentNodeState instances, thus falling back to the generic 
implementation in AbstractNodeState. For this specific case, where a large 
commit is compared with no or very few changes, this accellerated the commit 
hooks by a factor of ~10. I have tried to reproduce this in a synthetic 
benchmark, but there I only managed to produce a scenario that had comparable 
performance for both.

So while I don't understand the exact parameters, I provide this input in the 
hope that it will be helpful in resolving this issue. I'll also attach the 
benchmark class.

> Comparing node states for external changes is too slow
> ------------------------------------------------------
>
>                 Key: OAK-2829
>                 URL: https://issues.apache.org/jira/browse/OAK-2829
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core, mongomk
>            Reporter: Marcel Reutegger
>            Assignee: Marcel Reutegger
>            Priority: Blocker
>             Fix For: 1.3.0, 1.2.3
>
>         Attachments: CompareAgainstBaseStateTest.java, graph.png
>
>
> Comparing node states for local changes has been improved already with 
> OAK-2669. But in a clustered setup generating events for external changes 
> cannot make use of the introduced cache and is therefore slower. This can 
> result in a growing observation queue, eventually reaching the configured 
> limit. See also OAK-2683.



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

Reply via email to