Uploaded image for project: 'XWiki Platform'
  1. XWiki Platform
  2. XWIKI-7520

Activity Stream performance regression

    Details

    • Difficulty:
      Unknown
    • Similar issues:

      Description

      The activity stream has shown some serious slowness since 3.2. After a deep investigations we found some index issue but it was still slow with more than 5 items in most cases.

      After deeper investigations I found that the getRelatedEvents function was called a lot and got quite slow. I also found that the database seemed to spend some times querying an empty table activitystream_events_param although this table is empty by default with the current activity stream usage we do.

      I found this came from XWIKI-6839 and that by removing the <map> mapping from activitystream.hbm.xml the previous speed was recovered.

      Here are some speed results with activity entries="5" / with and without the mapping

      With Map
      Total time: 4766
      Some of the getRelatedEvents time (not all calls are timed): 1617

      Without Map:
      Total time: 750
      Some of the getRelatedEvents time (not all calls are timed): 175

      Though we need to seriously redesign the activity stream as we probably should not have to call getRelatedEvents that much, we need to get back to the previous speed.

      I don't really understand how querying an empty table even a lot of times can actually cost us 4 seconds. There seems to be something wrong either in the hibernate or in the mysql level.

      Either somebody can find it, either I recommend getting rid of that mapping until we find a solution. At this point I don't think the feature is needed.

        Attachments

        1. MySQL35M1.png
          MySQL35M1.png
          105 kB
        2. MySQL35SNAP.png
          MySQL35SNAP.png
          105 kB
        3. Oracle35M1.png
          Oracle35M1.png
          63 kB
        4. Oracle35SNAP.png
          Oracle35SNAP.png
          66 kB

          Issue Links

            Activity

              People

              • Assignee:
                vmassol Vincent Massol
                Reporter:
                ludovic Ludovic Dubost
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Date of First Response: