Attention : vous consultez actuellement la documentation dédiée aux versions 1.x de Moodle. La documentation pour les versions 2.x de Moodle est consultable ici : Performance, celle pour les versions 3.x de Moodle est consultable ici : Performance et celle pour Moodle 4.x est consultable là : Performance.

« Performance » : différence entre les versions

De MoodleDocs
Aller à :navigation, rechercher
Aucun résumé des modifications
Aucun résumé des modifications
Ligne 2 : Ligne 2 :
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 (jetez un oeil à la liste des [[:en:Large installations|grosses installations de Moodle]]).
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 (jetez un oeil à la liste des [[:en:Large installations|grosses installations de Moodle]]).


Large sites usually separate the web server and database onto separate servers, although for smaller installations this is typically not necessary.
Les grands sites séparent généralement le serveur web et la base de données sur des serveurs différents, ce qui n'est généralement pas nécessaire pour des installations de taille moyenne.


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).
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).
Ligne 13 : Ligne 13 :
* Les performances de PHP sont meilleures s'il est installé comme un module Apache (plutôt que CGI).
* Les performances de PHP sont meilleures s'il est installé comme un module Apache (plutôt que CGI).
* Sur un système Unix/Linux, les performances peuvent être améliorées en autorisant l'usage des commandes systèmes '''zip/unzip/du''' (plutôt que les librairies PHP) - visiter Administration/Configuration/Paramètres techniques et saisissez le chemin des exécutables concernés. (Similarly, filling in the path to '''du''' will improve Moodle's speed at listing directory contents.)
* Sur un système Unix/Linux, les performances peuvent être améliorées en autorisant l'usage des commandes systèmes '''zip/unzip/du''' (plutôt que les librairies PHP) - visiter Administration/Configuration/Paramètres techniques et saisissez le chemin des exécutables concernés. (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.
* Notez qu'utiliser des '''connections web sécurisées ''' ('''https''' plutôt que '''http''') implique un temps de traitement supérieur, à la fois du côté serveur web que client, notamment car le cache ne peut pas être utilisé aussi efficacement, et le nombre de requêtes de fichier augmente donc considérablement. Pour cette raison, utiliser https pour toutes les pages Moodle '''n'est pas''' recommandé. Vous pouvez autoriser https uniquement pour la page de connexion, simplement, depuis la page de configuration de Moodle.
* You can increase performance by using the light-weight webserver [http://www.lighttpd.org/ 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.
* You can increase performance by using the light-weight webserver [http://www.lighttpd.org/ 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. ([http://moodle.org/mod/forum/discuss.php?d=39656 Suggested by Rory Allford])
* 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. ([http://moodle.org/mod/forum/discuss.php?d=39656 Suggested by Rory Allford])
Ligne 25 : Ligne 25 :
== Performance de différents modules Moodle ==
== Performance de différents modules 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:
Les modules d'activité, filtres et autres plugins de Moodle peuvent êtres activés/désactivés. Si nécessaire, vous pourriez désactiver certaines fonctionnalités (comme le chat), si vous ne les utilisez pas - mais ce n'est pas obligatoire. Quelques notes sur les performances de certains modules :


* The '''Chat''' module is [http://moodle.org/mod/forum/discuss.php?d=37979&parent=175079 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.
* Le module '''Chat''' est [http://moodle.org/mod/forum/discuss.php?d=37979&parent=175079 réputé] pour être très consommateur de requêtes HTTP fréquentes au serveur principal. 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.
* [http://moodle.org/mod/forum/discuss.php?d=25616&parent=120770 Brief report on performance for 55 students simultaneously using '''Quiz''']
* [http://moodle.org/mod/forum/discuss.php?d=25616&parent=120770 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.
* 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.
Ligne 34 : Ligne 34 :
== Voir aussi ==
== Voir aussi ==


*Using Moodle [http://moodle.org/mod/forum/view.php?f=94 Servers and Performance] forum
* Le forum [http://moodle.org/mod/forum/view.php?f=94 Servers and Performance] (en anglais) sur Using Moodle


[[Category:Administrateur]]
[[Category:Administrateur]]

Version du 26 octobre 2006 à 04:32

Remarque : cet article est en cours de rédaction. N'hésitez pas à le compléter. Veuillez utiliser la page de discussion pour vos recommandations et suggestions d'améliorations.


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 (jetez un oeil à la liste des grosses installations de Moodle).

Les grands sites séparent généralement le serveur web et la base de données sur des serveurs différents, ce qui n'est généralement pas nécessaire pour des installations de taille moyenne.

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).

Performance du serveur web

  • La quantité de mémoire de travail (RAM) sur votre serveur web est le facteur le plus important pour la performance : installez autant de RAM que possible (par exemple 4 Go).
  • Linux ou Unix est le système d'exploitation recommandé pour le serveur. Il supporte beaucoup mieux la montée en charge que Mac OSX ou Windows.
  • Vous êtes fortement encouragé à utiliser un accélérateur PHP pour baisser la charge CPU, comme Turck MMCache ou PHPA.
  • Les performances de PHP sont meilleures s'il est installé comme un module Apache (plutôt que CGI).
  • Sur un système Unix/Linux, les performances peuvent être améliorées en autorisant l'usage des commandes systèmes zip/unzip/du (plutôt que les librairies PHP) - visiter Administration/Configuration/Paramètres techniques et saisissez le chemin des exécutables concernés. (Similarly, filling in the path to du will improve Moodle's speed at listing directory contents.)
  • Notez qu'utiliser des connections web sécurisées (https plutôt que http) implique un temps de traitement supérieur, à la fois du côté serveur web que client, notamment car le cache ne peut pas être utilisé aussi efficacement, et le nombre de requêtes de fichier augmente donc considérablement. Pour cette raison, utiliser https pour toutes les pages Moodle n'est pas recommandé. Vous pouvez autoriser https uniquement pour la page de connexion, simplement, depuis la page de configuration de Moodle.
  • 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)

Performances de Base de données

Performance de différents modules Moodle

Les modules d'activité, filtres et autres plugins de Moodle peuvent êtres activés/désactivés. Si nécessaire, vous pourriez désactiver certaines fonctionnalités (comme le chat), si vous ne les utilisez pas - mais ce n'est pas obligatoire. Quelques notes sur les performances de certains modules :

  • Le module Chat est réputé pour être très consommateur de requêtes HTTP fréquentes au serveur principal. 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.

Voir aussi