In addition to caching, Moodle offers a wide range of system-related performance settings that are set at various places in the Site administration section.
A session is initiated for each user who authenticates against Moodle. This also applies to guests. There are a number of relevant settings, which can be found by going to Server | Session handling:
|
Setting |
Description |
|---|---|
|
Use the database for session handling |
By default, session information is stored in the filesystem. On larger installations or a system that makes use of a clustered environment, it is recommended that you store the information in the Moodle database instead. |
|
Timeout |
The period for which a session is kept open when there hasn't been any activity. |
|
Cookie prefix |
This setting is only relevant if you run more than a single Moodle instance on the same web server and try to open instances of both in the same web browser. If this is the case, give the cookie a name on each site to avoid any conflicts. |
|
Cookie path |
Only change the location of where cookies are stored if there is a requirement for this in your environment. |
|
Cookie domain |
If your Moodle system shares its cookie space with another application, you can modify the domain that they both use. Be careful with this setting as it can prevent users from logging in if not specified correctly! |
Moodle manages sessions and cookies very well. However, when problems occur, it is sometimes necessary to intervene manually. This should be done locally in the web browser if a specific user experiences issues (clear cache and cookies) or on the server if the problem affects multiple users. The latter is done by clearing the mdl_sessions table if sessions are stored in the database or by emptying the $CFG->dataroot/sessions directory if sessions are stored in files. Bear in mind that all logged in users will be logged out.
We have already covered this as part of the installation, but it is worth reiterating that the method of how you call the Moodle cron job can have a significant impact on the performance of the system, especially on larger installations.
If the cron.php script is invoked over HTTP (either using wget or curl), more memory is used than calling directly via the php –f command.
Moodle comes with a task scheduler (Server | Scheduled tasks) that lets you precisely configure which routine job is running when and how often.
The following information is provided for each scheduled task:
|
Field |
Description |
|---|---|
|
Name |
Name and internal location of the task. |
|
Component |
Moodle component that triggers the task. |
|
Last run |
Date and timestamp when the task has been run or Never (if it has never run). |
|
Next run |
Date and timestamp when of when the task has been run or ASAP (if it has never run). |
|
Minute, Hour, Day, Day of week, Month |
Schedule information in Unix cron format:
|
|
Fail delay |
Number of seconds to wait before reattempting a failed task. |
|
Default |
Specifies whether the task has been modified (as shown in the following screenshot). |
If you wish to change the schedule for any of the tasks, you will need to select the Configuration icon in the Edit column. As an example, we have selected the Check for updates task:
In addition to the already covered scheduling settings, you also have the option to pause a task (Disabled) and revert the original settings (Reset task schedule to defaults). The default settings have been set with performance in mind. However, you might want to fine-tune these considering any idiosyncrasies in your setup.
Moodle's memory management has proven to be very efficient. However, there are scenarios when extra memory is required to execute complex PHP scripts. The cron is a candidate of such a complex script as is the course backup. To increase the memory limit, increase the Extra PHP memory limit setting by going to Server | Performance.
A number of Moodle modules offer settings that have an impact on the performance of your Moodle system.
Due to the complexity of the gradebook, there are a number of settings in the Grades menu that will have an impact on performance. In general, when more aggregation and other calculations have to be carried out, the population of the gradebook data store becomes slow. For example, the Aggregate including subcategories parameter that you see when you navigate to Grades | Grade category settings will add some minor overhead to the calculation of grades.
A second gradebook-related area that has an impact on performance is the Gradebook history, which forces Moodle to keep track of any changes in grades. Go to Server | Cleanup, and you will see two grade book history settings at the bottom.
The gradebook history is turned on by default and values are kept forever. You can either turn the facility off completely, or limit the number of days you wish to keep the grade entries.
By default, Moodle chat uses AJAX method, which, like Normal method, contacts all participating clients on a regular basis. The upside of both approaches is that they require no configuration and work on any system; the downside is that they have a significant performance impact on the server, especially when the chat activity is used regularly. The solution to this is to use Chat server daemon, which ensures a scalable chat environment. However, the daemon, a small system-level program that runs in the background, has to be installed on the operating system level and only works on Unix (check your administration guide for how to do this).
To change the chat method Moodle uses and configure a number of performance parameters, go to Plugins | Activity modules | Chat. We dealt with these in the synchronous communication section in Chapter 9, Moodle Configuration.
The following table lists the settings that are performance-related and the context (that is, the chat method used) in which they apply.
|
AJAX method |
Normal method |
Server daemon | |
|---|---|---|---|
|
Refresh user list |
|
|
|
|
Disconnect timeout |
|
|
|
|
Refresh room |
| ||
|
Update method |
| ||
|
Max users |
|
Finally, we deal with a number of performance-related settings that do not belong to any category described so far.
As you will learn in the next chapter, course backups have a negative impact on performance during their execution, especially on larger systems. If possible, schedule the backup procedure when the load on the overall system is low. If you turn off site-wide course backups and use system-level backups instead, you avoid performance problems, but you lose the ability to recover individual items. A compromise is to include only important data and leave out less relevant information, such as log files. All this will be dealt with in Chapter 13, Backup and Restore.
In Chapter 10, Moodle Logging and Reporting, we looked at Moodle logging, reporting, and analytics. Keeping track of user behavior can potentially have a negative impact on your server.
If you make use of the standard log as a log store (as opposed to an external database), you have the ability via the log store settings to specify the number of days for which user data is kept (the Keep logs for parameter). Here, you can also turn off the logging access of guests (Log guest access) and specify Write buffer size. You can further limit the number of days that the so-called backup log is being kept—you can find the Keep log for setting by going to Courses | Backups | General backup defaults.
If you have enabled the statistics functionality, be aware that it is likely to have a profound impact on the performance of your system whenever statistical information is updated. Go back to the section on Statistics settings in Chapter 10, Moodle Logging and Reporting, (Server | Statistics), and make sure that the configuration is set to have minimum impact on the server.
An operation that Moodle performs regularly is the listing of directories. The operation can either be run using Moodle's internal routine coded in PHP or, alternatively, by a native version of the function provided by the host operating system. The latter approach is significantly faster since it reduces the load on your server, but it is only supported in Unix environments.
You can specify the path for the du command by navigating to Server | System paths. On most systems, the location of the executable is /usr/bin/du. If this does not work, run the which du command on the Unix shell to find out where the programs are located. Once specified correctly, this will accelerate the displaying of the directory content, especially if they contain a lot of files.
The front page is likely to be accessed frequently by all users. On sites with a large number of courses, displaying all of them every time that the front page is called is unlikely to be a pleasant user experience. You can limit Maximum number of courses and Maximum category depth by going to Front page | Front page settings.
We dedicated an entire chapter to the management of roles. Its powerful flexibility comes at a price, which is a minor drop in performance if a lot of lookups are required in the context hierarchy (avoid global roles) and the override mechanism is applied frequently.
There is also a performance-related setting when it comes to displaying the number of users in the user selector, namely Maximum number of users per page, by navigating to Users | Permissions | User policies. If you experience speed problems in courses with a large number of users, change this setting and monitor the performance. We will deal with this next.