The performance of web-based systems is a critical issue, and it is the key responsibility of an administrator to configure, monitor, and fine-tune the virtual learning environment for maximum speed. While Moodle has the potential to scale to thousands of simultaneous users, good performance management is required to guarantee adequate scalability.
After providing an overview of the subject, we will cover the most relevant topics that are related to Moodle's performance and optimization.
We will conclude the chapter with a section on Moodle performance profiling and monitoring.
Web applications, in general, and Moodle, in particular, have very distinct application layers consisting of an operating system, web server, database server, and an application that's developed in a programming language. Each layer has its own idiosyncrasies when it comes to optimization. We will mainly focus on the application layer, which is the focus of this book.
The following areas are not dealt with in any detail in the following pages, and it is necessary to refer to the respective documentation with regard to performance and optimization issues:
$CFG->dbhost
entry in config.php
from localhost
to the IP address of your database. The latter is significantly more complex and requires strong database administration skills.There is also much debate about what database is best suited for Moodle. While the open source camp is divided between MySQL, MariaDB, and PostgreSQL, corporates are split between MS SQL Server and Oracle. Whatever your choice of system, a well set up and tuned database will always perform better than one that is used with out-of-the-box settings—"The best database system is the one you know".
php.ini
file will have to contain the following entries (for details, refer to https://docs.moodle.org/en/OPcache):[opcache] opcache.enable = 1 opcache.memory_consumption = 128 opcache.max_accelerated_files = 8000 opcache.revalidate_freq = 60 ; Required for Moodle opcache.use_cwd = 1 opcache.validate_timestamps = 1 opcache.save_comments = 1 opcache.enable_file_override = 0
While all the preceding criteria apply, some elements can be changed on the fly. For example, during exam week, you might consider increasing the memory available for Moodle, while during the summer break, you can reduce the number of servers to carry out maintenance. More sophisticated setups let you specify load and usage thresholds, which trigger the allocation of resources automatically.
For each area that's mentioned, benchmark and stress tests are available, and they will help you to gauge what performance bottlenecks are present and, after optimization has been carried out, if they have been reduced. There are also add-ons available for most web browsers that display information on how long it takes to load pages, thus offering some indicative performance measurements.
An entire area has been dedicated to performance and optimization in the Moodle Docs. You can find most of the relevant information as well as links to related sites at https://docs.moodle.org/en/Performance.
One thing that you should bear in mind is that Moodle's performance cannot be viewed without taking its security into account and vice versa. Very often, improving security comes at a price in terms of performance reduction; for example, running your entire site over HTTPS is often required and recommended, but it will slow down certain operations.
Another trade-off you will face regularly is performance versus functionality. Regularly, certain features, for example, the statistics module, will have a negative impact on how speedily your system performs. Moodle comes with a very basic performance report (Reports | Performance overview), which shows some trade-offs.
Let's consider an important issue: Automatic backup. This has an obvious impact on performance, but since you are unlikely to turn off backups, we will have to accept the fact that this will decrease the responsiveness of Moodle while backups are running unless you run backups on a dedicated server.
13.59.79.176