Uploaded image for project: 'Confluence Server'
  1. Confluence Server
  2. CONFSERVER-53503

"Move page" is 85% slower in Confluence 5.10+ than in 5.8.18, making moving large number of pages very inefficient

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Gathering Impact
    • Priority: Low
    • Resolution: Unresolved
    • Affects Version/s: 5.10.0
    • Fix Version/s: None
    • Component/s: Server - Performance
    • Labels:
      None

      Description

      We are developers of the Archiving Plugin for Confluence.

      Our add-on batch-archives pages by moving them between spaces. Our customers frequently archive tens of thousands of pages in one go, sometimes even more. "Page move" does not need to be hyper-fast, but is expected to be complete in tens of minutes or in some hours most (overnight) even for this scale of data.

      "Page move" has been a fairly fast operation in Confluence 5.7, and it became significantly slower some time between 5.7 and 5.10. (As far as I know the "Move page" feature has been rewritten in some Confluence version released around that time.)

      Our profiling results:

      Operation 1.014M pages in Confluence 5.7.6 5.8.18 metric 380K pages in Confluence 5.10.1
      Page archiving with MOVE 40 minutes (for 1555 pages) N/A 1.1 hours (for 400 pages - stable, but slower!)

      1555/40 = 39 page moved per minute in Confluence 5.7
      400/66 = 6 page moved per minute in Confluence 5.10

      6/39 means it is 85% slower than it used to be!

      Is there any chance to accelerate page moves in Confluence core?
      Or offer an API to batch-move multiple pages? (Currently, the API limits us to move one page at a time.)

      *Update 02/06/2017*

      Joint investigation by Aron Gombas [Midori] and Petro Semeniuk (see comment thread below) showed that regression happened somewhere between 5.8.18 and 6.0.1:

        5.8.0 5.8.18 6.0.1
      Execution time 23 m 10 s 12 m 36 s 23 m 53 s

      Regression is present both in memory consumption and cpu usage. As Aron proved increasing memory brings page move time by 30% but it still not up to par with what it was.

      Possible area is either `DefaultRelatedContentRefactorer` class or it's clients.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                9 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Last commented:
                  42 weeks, 3 days ago