Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-17499

Diffs take too long to execute sometimes

XMLWordPrintable

    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      Some content takes a really long time to diff. For example, a large set of changes on the Sales FAQ page on Extranet can take around 100 ms to diff, on an unloaded box.

      We should investigate why this is the case and try to improve the performance here if possible.

        1. Screen shot 2010-11-23 at 10.13.34 AM.png
          Screen shot 2010-11-23 at 10.13.34 AM.png
          180 kB
        2. Screen shot 2010-11-23 at 10.17.15 AM.png
          Screen shot 2010-11-23 at 10.17.15 AM.png
          115 kB

          Form Name

            [CONFSERVER-17499] Diffs take too long to execute sometimes

            Don Willis added a comment -

            Page diffs are now cached in memory to prevent pathalogical diffs bringing down the system.

            Don Willis added a comment - Page diffs are now cached in memory to prevent pathalogical diffs bringing down the system.

            Matthew Erickson added a comment -

            This problem was also causing an issue for the activity stream plugin. The solution there was to limit the max page size that we would attempt to diff. See http://svn.atlassian.com/fisheye/changelog/public/atlassian/studio/activity-stream/trunk/streams-confluence-plugin/src?cs=38109

            Matthew Erickson added a comment - This problem was also causing an issue for the activity stream plugin. The solution there was to limit the max page size that we would attempt to diff. See http://svn.atlassian.com/fisheye/changelog/public/atlassian/studio/activity-stream/trunk/streams-confluence-plugin/src?cs=38109

            Matt Ryall added a comment -

            To explain my thinking: 100ms is about the time it takes to render an entire Confluence page and send it over the LAN to your browser. By comparison, comparing two Strings of a reasonable size (less than 100,000 characters) that are already in memory should be orders of magnitude faster, I think. I suspect there are serious inefficiencies in the diff algorithm and it might be worth investigating why that is the case.

            I agree that caching the diffs is a good alternative and may be simpler to implement. In this case, I'd recommend the diff calculation be queued to start after the request finishes. This way, it will not be any unnecessary waiting when the page is saved. Notifications which are rendered using the diff would need to be placed in the same queue, so as to use the calculated diff.

            Matt Ryall added a comment - To explain my thinking: 100ms is about the time it takes to render an entire Confluence page and send it over the LAN to your browser. By comparison, comparing two Strings of a reasonable size (less than 100,000 characters) that are already in memory should be orders of magnitude faster, I think. I suspect there are serious inefficiencies in the diff algorithm and it might be worth investigating why that is the case. I agree that caching the diffs is a good alternative and may be simpler to implement. In this case, I'd recommend the diff calculation be queued to start after the request finishes. This way, it will not be any unnecessary waiting when the page is saved. Notifications which are rendered using the diff would need to be placed in the same queue, so as to use the calculated diff.

            Don Willis added a comment -

            100ms is not that long for a single operation. The problem is that sometimes (see CONF-16596) we get many attempts to diff the same page. It seems logical that we should cache diffs, since unlike rendered content, they are the same for all users.
            I would go a step further actually and store the diff between one page and its predecessor in the database at the time of the update.

            Don Willis added a comment - 100ms is not that long for a single operation. The problem is that sometimes (see CONF-16596 ) we get many attempts to diff the same page. It seems logical that we should cache diffs, since unlike rendered content, they are the same for all users. I would go a step further actually and store the diff between one page and its predecessor in the database at the time of the update.

              don.willis@atlassian.com Don Willis
              matt@atlassian.com Matt Ryall
              Votes:
              3 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: