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.
- Moodle content: We will look into how content creation, content volume, different content types, and various filter settings can impact the performance of your Moodle system.
- Moodle Universal Cache: We look at the different elements of the powerful Moodle Universal Cache (MUC), namely cache types, cache stores, and cache definitions. We will then run you through performance testing of the MUC as well different caching options.
- Moodle system settings: A range of system-related performance settings are dealt with, namely:
- Session handling
- Cron management and scheduled tasks
- Module settings (gradebook, chat, and forum)
- Miscellaneous settings (course backups, log files, system paths, front page courses, as well as roles and users)
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:
- Operating system performance: The choice of operating system and its configuration will have a major impact on how Moodle performs. In principle, Linux or any other Unix derivative performs better than any other operating system. PHP applications, such as Moodle, run significantly slower in a Windows environment than on Linux. Some aspects of this have been covered in Chapter 1, Moodle Installation, when we dealt with the installation of Moodle.
- Database performance: The database is the core element of Moodle, but it's also a major bottleneck since it requires disk access, which is slower than memory access. Entire books and conferences have been dedicated to database optimization with indexing, caching, buffering, querying, and connection handling as the main candidates of discussion. The two optimizations that have a significant impact on your database performance are enabling of query caching and an increase in buffer sizes. You might also want to consider running the database on a separate dedicated server or a cluster. The former is relatively straightforward: once set up, all you need to do is to change the
$CFG->dbhostentry inconfig.phpfromlocalhostto 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".
- Web server performance: Each web server (Apache, IIS, NginX, and so on) offers an array of optimization settings that include memory handling, caching, process management, and other minor tweaks that are made to it.
- PHP performance: There are a number of ways in which PHP can be forced to execute code significantly faster. The key to doing this is using a PHP accelerator in combination with good memory management and caching techniques. Moodle supports OPcache from Zend, which has been precompiled from PHP 5.5 onwards. Zend OPcache speeds up PHP execution by opcode caching and optimization. It stores precompiled script byte code in shared memory. You can check whether OPcache is working correctly by going to Server | Environment:
- Your
php.inifile 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
- Your
- Hardware performance: We already covered some aspects of this in Chapter 1, Moodle Installation, where we mentioned that there is no one-size-fits-all approach when it comes to the ideal hardware setup. For single server systems, the key is RAM: the more, the better. It's as simple as that. Once the level of concurrency increases above a certain level, it is inevitable to use multiple web servers in a load-balanced environment.
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.