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

Performance: Modinfo cache can get built in parallel

    XMLWordPrintable

    Details

    • Affected Branches:
      MOODLE_33_STABLE, MOODLE_34_STABLE
    • Fixed Branches:
      MOODLE_33_STABLE, MOODLE_34_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      MDL-61305-master
    • Pull Master Diff URL:
    • Testing Instructions:
      Hide
      1. As admin, go to any course page on your test system.
      2. Enrol a test user account in the course (or use an existing one).
      3. Open a second browser, go to the same course page, and log in using the test account.
      4. Make a code change (just for testing) to lib/modinfolib.php:
        1. Search for the comment: // Retrieve all information about activities and sections.
        2. Immediately above this line, add the following line: sleep(10); debugging('Actually building course cache');
      5. Using the admin browser, edit course settings. Without making a change, click Save and display
      6. Using the other (user) browser, load the course page again. (You need to do this step within ten seconds - ideally a couple of seconds after hitting save in the admin browser.)
        • EXPECTED: The admin browser takes 10 seconds then displays debugging info about rebuilding the course cache.
        • EXPECTED: The other browser finishes slightly faster - it should load immediately after the admin browser does.There should be no debugging info.
      7. In the admin browser, open a new tab on the Site administration page, and go to Plugins / Caching / Configuration.
      8. Find the coursemodinfo cache area, and click Purge next to it (if you can't see that link, try making your browser ginormously wide).
      9. Wait for this to finish.
      10. In the user browser, reload the course page.
      11. In the admin browser, go back to the course page tab and reload it.
        • EXPECTED: The user browser takes 10 seconds then displays the page, including debugging info about rebuilding the course cache.
        • EXPECTED: The admin browser finishes immediately after the user browser does, and there should be no debugging info.
      Show
      As admin, go to any course page on your test system. Enrol a test user account in the course (or use an existing one). Open a second browser, go to the same course page, and log in using the test account. Make a code change (just for testing) to lib/modinfolib.php: Search for the comment: // Retrieve all information about activities and sections. Immediately above this line, add the following line: sleep(10); debugging('Actually building course cache'); Using the admin browser, edit course settings. Without making a change, click Save and display Using the other (user) browser, load the course page again. (You need to do this step within ten seconds - ideally a couple of seconds after hitting save in the admin browser.) EXPECTED: The admin browser takes 10 seconds then displays debugging info about rebuilding the course cache. EXPECTED: The other browser finishes slightly faster - it should load immediately after the admin browser does.There should be no debugging info. In the admin browser, open a new tab on the Site administration page, and go to Plugins / Caching / Configuration . Find the coursemodinfo cache area, and click Purge next to it (if you can't see that link, try making your browser ginormously wide). Wait for this to finish. In the user browser, reload the course page. In the admin browser, go back to the course page tab and reload it. EXPECTED: The user browser takes 10 seconds then displays the page, including debugging info about rebuilding the course cache. EXPECTED: The admin browser finishes immediately after the user browser does, and there should be no debugging info.

      Description

      In a large course, rebuilding the modinfo cache (for example when caches are purged, or when you edit a setting on the course) can take a significant amount of time, for example 5 seconds.

      With a busy system it is possible that multiple users may access the course within that period. Currently, all of them will result in a cache rebuild. This process is expensive for the database and could cause noticeable delays for users if staff are editing a busy course while students are using it.

      Assuming the database has unlimited capacity, here is what the current situation looks like, with R being when a user makes a request, and D when it's done:

      User 1 R...............D (5s) - rebuilds cache
      User 2 ...R...............D (5s) - rebuilds cache
      User 3 ......R...............D (5s) - rebuilds cache

      Here is the ideal situation:

      User 1 R...............D (5s) - rebuilds cache
      User 2 ...R............D (4s) - waits for rebuild
      User 3 ......R.........D (3s) - waits for rebuild

      As you can see this would result in better performance for users in these cases. It also means the database has 1/3 the work to do, which may be important if you are unlucky enough to have a database without unlimited capacity. (We think this might possibly contribute to one of the situations when our system gets a hiccup.)

      It should be possible to implement this behaviour using the Moodle locking mechanism.

        Attachments

          Issue Links

          has a non-specific relationship to

          Improvement - An enhancement to an existing Moodle feature. MDL-55231 Partial course cache rebuild

          • Major - Major loss of function, incorrect output
          • Closed
          has been marked as being related by

          Bug - A problem which impairs or prevents Moodle from functioning correctly. MDL-67020 The coursemodinfo cache item doesn't scale when localized due to global locking

          • Minor - Minor loss of function where workaround is possible
          • Open

          Bug - A problem which impairs or prevents Moodle from functioning correctly. MDL-67674 Performance: Course category tree cache can get built in parallel

          • Major - Major loss of function, incorrect output
          • Closed

            Activity

              People

              Assignee:
              quen Sam Marshall
              Reporter:
              quen Sam Marshall
              Integrator:
              Andrew Lyons Andrew Lyons
              Tester:
              Gladys Basiana Gladys Basiana
              Participants:
              Component watchers:
              Matteo Scaramuccia, Amaia Anabitarte, Carlos Escobedo, Ferran Recio, Ilya Tregubov, Sara Arjona (@sarjona), Amaia Anabitarte, Carlos Escobedo, Ferran Recio, Ilya Tregubov, Sara Arjona (@sarjona), Matteo Scaramuccia, Andrew Lyons, Dongsheng Cai, Huong Nguyen, Jun Pataleta, Michael Hawkins, Shamim Rezaie, Simey Lameze
              Votes:
              3 Vote for this issue
              Watchers:
              9 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Fix Release Date:
                19/Mar/18

                  Time Tracking

                  Estimated:
                  Original Estimate - 0 minutes
                  0m
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 1 hour, 30 minutes
                  1h 30m