Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-61409

For users with access to a lot of courses, calendar event creation dialog is intolerably slow.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Duplicate
    • Affects Version/s: 3.4.1
    • Fix Version/s: None
    • Component/s: Calendar, Groups
    • Labels:
    • Testing Instructions:
      Hide
      • Create a large site (~1000 courses, ~300 students per course, 20000 groups)
      • Log in as site admin
      • Go to calendar view
      • Click "New Event" button
      • Observe time to dialog creation, then time to dialog usable
      • Create an event, submit form
      • Observe time to completion of submission

      Apply patch, repeat.

      Alternatively, profile the above, read the code, consider the inefficiency of loading all groups, including memberships...

      Show
      Create a large site (~1000 courses, ~300 students per course, 20000 groups) Log in as site admin Go to calendar view Click "New Event" button Observe time to dialog creation, then time to dialog usable Create an event, submit form Observe time to completion of submission Apply patch, repeat. Alternatively, profile the above, read the code, consider the inefficiency of loading all groups, including memberships...
    • Affected Branches:
      MOODLE_34_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      MDL-61409-master

      Description

      For a site with a lot of courses, and using groups extensively, the calendar event creation dialog can now be intolerably slow (up to 90s or more) to appear and to save.

      Memory usage is also ludicrously high.

      This is still a problem even with Ryan's calendar-performance-related patches all applied (MDL-60959, MDL-60960, MDL-60962, MDL-60963, MDL-60966, MDL-60958).

      Profiling shows the problem to be calendar_get_all_allowed_types and its calling of groups_get_all_groups_for_courses.

      When this is getting details for a large number of courses, which use a large number of groups, with a large number of members, this is far too expensive and completely unnecessary. All that is needed is the group id, course id, group name, and whether the user is a member of the group.

      I have a fix that reduces the time required by an order of magnitude; it's not perfect, but demonstrates that significant improvement is possible in this area. Will attach it once I've tidied it up.

       

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                nwpotago Nick Phillips
                Reporter:
                nwpotago Nick Phillips
                Peer reviewer:
                Simey Lameze
                Participants:
                Component watchers:
                Andrew Nicols, Mathew May, Michael Hawkins, Shamim Rezaie, Simey Lameze, Andrew Nicols, Mathew May, Michael Hawkins, Shamim Rezaie, Simey Lameze
              • Votes:
                4 Vote for this issue
                Watchers:
                10 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: