[jira] [Commented] (OAK-2619) Repeated upgrades

["Julian Sedding (JIRA)" <ji...@apache.org>]

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

Julian Sedding commented on OAK-2619:
-------------------------------------

I have done some more measurements using both TarNS and MongoNS. My data for both backends shows that the initial upgrade (i.e. into an empty NodeStore) is equally fast with and without my changes. See initial-upgrade-tar.png and initial-upgrade-mongo.png respectively.

My measurements also show that an incremental upgrade can help save time on the critical path of an upgrade. Provided that the optimizations from OAK-2626 (and ideally OAK-2627) are applied.

In my tests, an initial upgrade of 500k nodes (~2/3 digital assets, ~1/3 websites) to TarNS took 52-55 sec. The incremental upgrade (with no changes in the source repo, i.e. best-case) with optimizations only took 15 sec. The work-load is equivalent to a single repository traversal with no writes and hence no additional traversal for the commit hooks.

On Mongo the results are similar, albeit more dramatic: the initial upgrade took 605-623 sec, while the incremental upgrade with optimizations took only 80 sec.

Note that for the not fully optimized cases incremental upgrades are slower (or not much faster) than initial upgrades.



> Repeated upgrades
> -----------------
>
>                 Key: OAK-2619
>                 URL: https://issues.apache.org/jira/browse/OAK-2619
>             Project: Jackrabbit Oak
>          Issue Type: New Feature
>          Components: upgrade
>    Affects Versions: 1.1.7
>            Reporter: Julian Sedding
>            Priority: Minor
>         Attachments: OAK-2619.patch, incremental-upgrade-no-changes-mongo.png, incremental-upgrade-no-changes-tar.png, initial-upgrade-mongo.png, initial-upgrade-tar.png
>
>
> When upgrading from Jackrabbit 2 to Oak there are several scenarios that could benefit from the ability to upgrade repeatedly into one target repository.
> E.g. a migration process might look as follows:
> # upgrade a backup of a large repository a week before go-live
> # run the upgrade again every night (commit-hooks only handle delta)
> # run the upgrade one final time before go-live (commit-hooks only handle delta)
> In this scenario each upgrade would require a full traversal of the source repository. However, if done right, only the delta needs to be written and the commit-hooks also only need to process the delta.



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