Moodle provides some basic profiling information that you can turn on in Development | Debugging, where you have to enable the Performance info option. This will display information about the execution time, RAM usage, number of files in use, CPU usage and load, session size, as well as various filter and caching measures (less information will be shown on a Windows-based installation).

It further displays information on the caches used in the particular page. For each cache, hits, misses, and sets are shown. The caches are highlighted using traffic light colors: red uses up the most, orange some, and green uses up the least amount of resources. This is a rather good indicator to identify performance issues.

The data will be displayed in the footer of Moodle as long as it is supported by the theme in use (for instance, Clean and More).

Moodle further supports profiling at the PHP level. While this is mainly targeted at developers, it may be helpful for administrators to identify bottlenecks in their system. Internal profiling is built on top of XHProf, which is a hierarchical profiler written by Facebook. It allows the profiling of PHP pages at a relatively low performance cost. First of all, you have to make sure that XHProf works on your server:

Once this is successful (check with php –m that the xhprof extension is listed), you will see a new menu item when you navigate to Development | Profiling.

The profiler can be configured to run automatically (set the Automatic profiling frequency to any value except 0, and specify URLs in the Profile these field) or manually. The latter can be Selective (you have to initiate the profiling) or Continuous (once it starts, you have to stop it).

As soon as profiling has been enabled, yet another menu item will appear when you go to Development | Profiling runs, which lists summary information on all the profile runs that have been executed:

When you click on the URL or date of a single run, you can mark the run as a reference and provide a comment for it. You can also view its profiling details, where execution times and memory usage of each function call are shown in tabular form.

From this table, you can view a call graph. However, this requires a dot to be installed (part of the Linux graphviz package) and a path to the dot (usually /usr/bin/dot) to be specified when you go to Server | System paths. The result is a scary looking graph showing the order, dependencies, and details of each function call.

The general strategy when dealing with profiling is to identify the functions that take the longest to execute, make tweaks to your setup, and check whether the time has reduced. The difficulty in doing this is to make sure that the test runs take place under the same or, at least, very similar conditions.

Moodle further comes with a nifty script that lets you generate random course data. This way, you can simulate having hundreds of courses with various levels and types of activities. You have to call the script manually at <yoursite>/admin/tool/generator. This is described in more detail in Chapter 14, Moodle Admin Tools.

In addition to the profiling information that Moodle provides, you can gather more data using a combination of system-level tools:

All the mentioned systems and tools are for Linux only, and you can find help on how to use them in their respective documentations.

Now that you have been armed with a number of profiling and monitoring tools, you can change the settings as described throughout the chapter. Take a look at what impact, positive or negative, they have on the performance of your Moodle system.