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

Performance: Modinfo cache can get built in parallel

XMLWordPrintable

    • MOODLE_33_STABLE, MOODLE_34_STABLE
    • MOODLE_33_STABLE, MOODLE_34_STABLE
    • MDL-61305-master
    • 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.

      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.

            quen Sam Marshall
            quen Sam Marshall
            Andrew Lyons Andrew Lyons
            Gladys Basiana Gladys Basiana
            Votes:
            3 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved:

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

                  Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.