Performance recommendations

Moodle can be made to perform very well, at small usage levels or scaling up to many thousands of users. The factors involved in performance are basically the same as for any PHP-based database-driven system, and Moodle's design (with clear separation of application layers) allows for strongly scalable setups. (Please check the list of large Moodle installations.)

Large sites usually separate the web server and database onto separate servers, although for smaller installations this is typically not necessary.

It is possible to load-balance a Moodle installation, for example by using more than one webserver. The separate webservers should query the same database and refer to the same filestore area, but otherwise the separation of the application layers is complete enough to make this kind of clustering feasible. Similarly, the database could be a cluster of servers (e.g. a MySQL cluster), but this is not an easy task and you should seek expert support, e.g. from a Moodle Partner.

The overall aim of adjustments to improve performance is to use RAM (cacheing) and to reduce disk-based activity. It is especially important to try to reduce swap file usage as much as you can.

Note: The fastest and most effective change that you can make to improve performance is to increase the amount of RAM on your web server - get as much as possible (eg 4GB). Increasing primary memory will reduce the need for processes to swap to disk and will enable your server to handle more users.

Web server performance

• Linux or Unix is recommended for the server operating system. *nix operating systems generally require less memory than Mac OS X or Windows servers for doing the same task as the server is configured with just a shell interface. Additionally Linux does not have licensing fees attached, but can have a big learning curve if you're used to another operating system. For the best in performance from your OS, you may also want to consider using Solaris which is also free.
• You are strongly recommended to use a PHP accelerator to ease CPU load, such as APC (recommended), PHPA, Xcache or eAccelerator. (Take care to choose a PHP accelerator that is known to work well with your version of PHP and note that Turck MMCache is no longer maintained and can cause failures with PHP 5).
• Performance of PHP is better when installed as an Apache module (rather than a CGI).
• Consider reducing the number of modules that Apache loads in the httpd.conf file to the minumum necessary to reduce the memory needed. Also, use the latest version of Apache 2, which reduces memory usage further.
• Alternatively, you can increase web server performance by using the light-weight webserver lighttpd in combination with PHP in fastCGI-mode instead of Apache. Lighttpd has a lower memory consumption than Apache. One single apache process requires more RAM than the whole lighttpd with all of its fastCGI-processes together. Note that Lighttpd is relatively difficult to configure and administration takes a more time.
• For Unix/Linux systems, consider lowering MaxRequestsPerChild in httpd.conf to as low as 20-30 (if you set it any lower the overhead of forking begins to outweigh the benefits).
• Also check the memory_limit in php.ini, reduce it to 16M for Moodle version earlier than 1.7 (See this forum discussion). For Moodle 1.7 or later, it is recommended that the value of memory_limit should be 32M.

Database performance

• Arguments in favour of PostgreSQL
• Increasing the database connection lifetime
• Tuning MySQL parameters (advice from the MySQL manual)

Moodle Admin settings

• Enable the language cache.
• Large log files can cause overall performance to degrade over time. If you observe that the site has gradually got slower loading pages in the browser, reduce your Log life time setting (Admin/Configuration/Variables/Maintenance).
• In Moodle 1.7 or later, enable the record cache. This will act as a primary cache and improve database access performance.
• Performance can be greatly improved by allowing Moodle to use the system zip/unzip commands (rather than PHP-based zip libraries) - visit Admin/Configure/Variables and enter the path to the relevant executables. (Similarly, filling in the path to du will improve Moodle's speed at listing directory contents.)
• Note that using secure web connections (https rather than http) carries a higher processing burden, both for the webserver and the client - particularly because cacheing cannot be used as effectively, so the number of file requests is likely to increase dramatically. For this reason using https for all Moodle pages is not recommended. You can enable https just for the login screen, simply from Moodle's config page.
• Check your filters. Having too many filters active can have serious effects on server load, especially on lower-end systems. The number of active filters has a direct effect on the perceived latency of your site; that is the time taken for each page impression.
• Enable the text cache but do not "Filter all strings" unless you have a specific need. If in doubt profile the performance, and see how your changes affect the processing time.
• Check your anti-virus measures on the server. Although they are useful for preventing security holes being exploited, some "On-Demand" scanners can affect performance by scanning page content (word, ppt files etc).

Performance of different Moodle modules

Moodle's activity modules, filters, and other plugins can be activated/deactivated. If necessary, you may wish to deactivate some features (such as chat) if not required - but this isn't necessary. Some notes on the performance of certain modules:

• The Chat module is said to be a hog in terms of frequent HTTP requests to the main server. This can be reduced by setting the module to use Streamed updates, or, if you're using a Unix-based webserver, by running the chat in daemon mode.
• The quiz activity is known to stretch database performance. Try to optimise your database server by tuning. See for a brief report on performance for 55 students simultaneously using quizzes
• The Moodle Cron task is triggered by calling the script cron.php. If this is called over HTTP (e.g. using wget or curl) it can take a large amount of memory on large installations. If it is called by directly invoking the php command (e.g. php -f /path/to/moodle/directory/admin/cron.php) efficiency can be much improved.

See also

• Using Moodle Servers and Performance forum
• Using Moodle Performance perspectives - a little script forum discussion