パフォーマンス

鋭意翻訳中です。

少ないユーザでも、スケールアップした数千名のユーザでも、Moodleを快適に稼動させることが可能です。パフォーマンスに関係する要素は、基本的にどのPHPベースのデータベース主導型システムとも同じです。 また、( アプリケーションレイヤと明確に分離された ) Moodleの設計により、強力に拡張性のあるセットアップを行うことが可能です。( 大規模なMoodleインストール一覧をご覧ください。)

大規模なサイトでは、通常ウェブサーバとデータベースサーバを分離します。しかし、小規模なサイトでは、サーバを分離することは通常必要ではありません。

例えば、1台以上のウェブサーバを使用して、Moodleをロードバランスした環境で使用することも可能です。ロードバランス用に分離された複数のウェブサーバでは、同一のデータベースおよび同一のファイル保存エリアを参照するようにしてください。しかし、ロードバランス環境でない場合、アプリケーションレイヤとデータベースの分離で十分にクラスタ化することができます。同様に、データベースをクラスタ化することも可能です ( 例 MySQLクラスタ )。

ウェブサーバパフォーマンス

• あなたのウェブサーバの「RAM」の容量はパフォーマンスに関する重要な要素です - 可能な限り多く設置してください ( 例 4GB)。
• LinuxまたはUnixがサーバに対するMoodle推奨「オペレーティングシステム」です。LinuxやUnixは、高負荷時にMac OSXやWindowsサーバよりも快適に動作します。
• CPUの負荷を軽減するため、Turck MMCacheまたはThe ionCube PHP Acceleratorのような、PHP acceleratorの利用を強くお勧めします。
• Performance of PHP is better when installed as an Apache module (rather than a CGI).
• On a Unix/Linux system, performance can be greatly improved by allowing the webserver 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.
• You can increase performance by using the light-weight webserver lighttpd in combination with PHP in fastCGI-mode instead of Apache, due to much lower memory consumption. One single apache process requires more RAM than the whole lighttpd with all of its fastCGI-processes together. Note that this may not be a good solution if you can afford lots of hardware power, because administration takes a little more time.
• 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 at least 16M. (Suggested by Rory Allford)

データベースパフォーマンス

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

各Moodleモジュールのパフォーマンス

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.
• Brief report on performance for 55 students simultaneously using Quiz
• 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.
• 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. For best performance, leave the text cache enabled and 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.

関連情報

• Using Moodleフォーラム Servers and Performance