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

Optimizations needed to reduce Moodle's memory footprint/load time.

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.4.1
    • Fix Version/s: DEV backlog
    • Component/s: Performance
    • Labels:
    • Affected Branches:
      MOODLE_24_STABLE

      Description

      Firstly my apologies if this is not the appropriately place for this.

      Over the past year and a bit I have spent working with moodle I have noticed a steady rise in the amount of memory usage and time it is taking to generate a page. As such I have decided to submit a ticket to hopefully identify some areas which have a noticeable performance impact on moodle and hopefully have some changes implemented to rectify these impacts.

      I write this ticket knowing full well that a way to limit these performance issues is using a PHP accelerator, better hardware etc. but I think it is still important to remedy these issues in the application itself where possible.

      After looking at moodle's code over the past few hours 2 areas in particular which I think could benefit from some changes are the following.

      1. The big block of require_once calls in lib/setup.php.

      Echoing the memory usage (memory_get_usage()) before and after all these libs are loaded shows an increase in RAM usage from ~1MB to ~17MB on my development machine.

      A lot of popular PHP frameworks and application use the 1 file per class rule and use an autoloader, I believe moodle could greatly benefit from a similar approach.

      Pros:

      • Can slowly do away with manual require and require_once's for classes as they being to use the autoloader.
      • Reduced memory usage and page generation time, dependent on what classes the page use.
      • spl_autoload_register was added in PHP 5.1.2 so it won't raise requirements for running moodle.

      Cons:

      • Lots of re-structuring of existing moodle components.
      • Procedural code/defines would still need to remain in files which are loaded every page request.

      2. Use AJAX to dynamically load sub-trees of the $ADMIN navigation block.

      Calling admin_get_root() as an admin user raised RAM usage by ~15MB and triples the amount of time it takes to load the moodle index page and adds ~25 queries to the page.

      Granted, an admin user isn't going to be the main user of a moodle installation but it is still an amazingly large bottleneck in moodle which could be fixed by using AJAX to populate the admin menu rather than loading it on each request.

      I look forward to hearing everyone's thoughts on these ideas and other areas moodle could be optimized. I also expect a bit of backlash on the first suggestion especially due to backwards compatibility and the amount of changes it would require.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              moodle.com moodle.com
              Reporter:
              raing3 Richard Ainger
              Participants:
              Component watchers:
              Matteo Scaramuccia, Andrew Nicols, Jun Pataleta, Michael Hawkins, Shamim Rezaie, Simey Lameze
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated: