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
Ligne 11 : Ligne 11 :
== Obtenir un benchmark de base ==
== Obtenir un benchmark de base ==


Before attempting any optimization, you should obtain a baseline benchmark of the component of the system you are trying to improve. For Linux try [http://lbs.sourceforge.net/ LBS] and for Windows use the Performance Monitor. Once you have quantitative data about how your system is performing currently, you'll be able to determine if the change you have made as has any real impact.
Avant de tenter la moindre optimisation, vous devriez obtenir un benchmark de base des composants que vous essayez d'améliorer. Pour Linux, essayez [http://lbs.sourceforge.net/ LBS] et pour Windows utilisez le Performance Monitor. Lorsque vous avez des données quantitatives sur les performances actuelles de votre système, vous pourrez déterminer si les changements que vous aurez apportés ont un réel impact.


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 eliminate swap file usage as much as you can. If your system starts swapping, this is a sign that you need more RAM.
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 eliminate swap file usage as much as you can. If your system starts swapping, this is a sign that you need more RAM.


The '''optimization order preference''' is usually: primary storage (more RAM), secondary storage (faster hard disks/improved hard disk configuration), processor (more and faster).
'''L'ordre d'optimisation préférentiel''' est généralement : stockage principal (plus de RAM), le stockage secondaire (disques durs plus rapides/meilleur configuration des disques durs), processeur (plus, et plus rapides).
 
== Configuration matérielle ==
== Configuration matérielle ==



Version du 16 janvier 2007 à 09:07

Remarque : la traduction de cet article n'est pas terminée. N'hésitez pas à traduire tout ou partie de cette page ou à la compléter. Vous pouvez aussi 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), but this is not an easy task and you should seek expert support, e.g. from a Moodle Partner.

The above comment makes it sound easy to run a database cluster. It is not. It is easy to run the webservers in cluster with LVM and other solutions. The only "easy" cluster database is MySQL Cluster and there are several issues with it. --Martin Langhoff 18:53, 31 August 2006 (CDT)

Obtenir un benchmark de base

Avant de tenter la moindre optimisation, vous devriez obtenir un benchmark de base des composants que vous essayez d'améliorer. Pour Linux, essayez LBS et pour Windows utilisez le Performance Monitor. Lorsque vous avez des données quantitatives sur les performances actuelles de votre système, vous pourrez déterminer si les changements que vous aurez apportés ont un réel impact.

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 eliminate swap file usage as much as you can. If your system starts swapping, this is a sign that you need more RAM.

L'ordre d'optimisation préférentiel est généralement : stockage principal (plus de RAM), le stockage secondaire (disques durs plus rapides/meilleur configuration des disques durs), processeur (plus, et plus rapides).

Configuration matérielle

Note : Le moyen le plus simple, rapide et efficace pour augmenter les performances est d'augmenter la mémoire sur votre serveur web - installez autant de RAM que possible (par exemple 4 Go). Increasing primary memory will reduce the need for processes to swap to disk and will enable your server to handle more users.

  • Better performance is gained by obtaining the best processor capability you can, i.e. dual or dual core processors. A modern BIOS should allow you to enable hyperthreading, but check if this makes a difference to the overall performance of the processors by using a CPU benchmarking tool.
  • If you can afford them, use SCSI hard disks instead of SATA drives. SATA drives will increase your system's CPU utilization, whereas SCSI drives have their own integrated processors and come into their own when you have multiple drives. If you must have SATA drives, check that your motherboard and the drives themselves support NCQ (Native Command Queuing).
  • Purchase hard disks with a low seek time. This will improve the overall speed of your system, especially when accessing Moodle's reports.
  • Size your swap file correctly. The general advice is to set it to 4 x physical RAM.
  • Use a RAID disk system. Although there are many different RAID configurations you can create, the following generally works best:
    • install a hardware RAID controller (if you can)
    • the operating system and swap drive on one set of disks configured as RAID-1.
    • Moodle, Web server and Database server on another set of disks configured as RAID-5.
  • Use gigabit ethernet for improved latency and throughput. This is especially important when you have your webserver and database server separated out on different hosts.

Système d'exploitation

  • Vous pouvez utiliser Linux(recommandé), Unix-based, Windows ou Mac OS X comme système d'exploitation pour le serveur. *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. If you have a large number of processors running SMP, you may also want to consider using a highly tuned OS such as Solaris.
  • Check your own OS and vendor specific instructions for optimization steps.
    • For Linux look at the Linux Performance Team site.
    • For Linux investigate the hdparm command, e.g. hdparm -m16 -d1 can be used to enable read/write on multiple sectors and DMA. Mount disks with the async and noatime options.
    • For Windows set the sever to be optimized for network applications (Control Panel, Network Connections, LAN connection, Properties, File & Printer Sharing for Microsoft Networks, Properties, Optimization). You can also search the Microsoft TechNet site for optimization documents.

Performances du serveur web

  • Performances de PHP
    • Vous êtes fortement encouragé à utiliser un accélérateur PHP pour baisser la charge CPU, comme APC (recommandé), PHPA, Xcache ou eAccelerator. (Prenez garde à choisir un accélérateur PHP qui fonctionne correctement avec votre version de PHP et notez que Turck MMCache n'est plus maintenu et peut provoquer des erreurs avec PHP 5).
    • Les performances de PHP sont meilleures s'il est installé comme un module Apache/IIS (plutôt que CGI).
    • Vérifiez également memory_limit dans php.ini, réduisez le à 16M pour les versions de Moodle jusqu'à 1.6 (See this forum discussion). A partir de Moodle 1.7 et suivant, il est recommandé que memory_limit soit à 32M.
  • Performances d'Apache
    • 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.
    • 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).
    • For a heavily loaded server, consider lowering the KeepAliveTimeout to between 2 and 5. The default is 15 (seconds) - the higher the value the more server processes will be kept waiting for possibly idle connections.
    • 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.
  • IIS performance - all alter this location in the registry:
 HKLM\SYSTEM\CurrentControlSet\Services\Inetinfo\Parameters\
  • The equivalent to KeepAliveTimeout is ListenBackLog (IIS - registry location is HKLM\ SYSTEM\ CurrentControlSet\ Services\ Inetinfo\ Parameters). Set this to between 2 to 5.
  • Change the MemCacheSize value to adjust the amount of memory (Mb) that IIS will use for its file cache (50% of available memory by default).
  • Change the MaxCachedFileSize to adjust the maximum size of a file cached in the file cache in bytes. Default is 262,144 (256K).
  • Create a new DWORD called ObjectCacheTTL to change the length of time (in milliseconds) that objects in the cache are held in memory. Default is 30,000 milliseconds (30 seconds).

Performances de Base de données

Voici quelques paramètres spécifiques à MySQL qui peuvent être ajustés dans votre fichier my.cnf (my.ini pour Windows), afin d'apporter de meilleurs performances. Pour voir les valeurs actuelles, utilisez ces commandes :

 SHOW STATUS;
 SHOW VARIABLES;

Important : vous devez faire des sauvegardes de votre base de données avant de modifier la configuration de votre serveur MySQL. Après chaque changement du fichier my.cnf, redémarrez mysqld.

  • Autorisez le cache de requête avec query_cache_type = 1. For most Moodle installs, set the query_cache_size to 36M and query_cache_min_res_unit to 2K. The query cache will improve performance if you are doing few updates on the database.
  • Set the table cache correctly. For Moodle 1.6 set this as table_cache = 159, and for Moodle 1.7 set table_cache = 170. Note that this figure will change depending on the number of modules and plugins you have installed. Find the number for your server by executing the mysql statement below. Look at the number of rows printed and set table_cache to this value.
 mysql>SELECT table_name FROM information_schema.tables WHERE table_schema='yourmoodledbname';
  • Set the thread cache correctly. Adjust the value so that your thread cache utilization is as close to 100% as possible by this formula:
 thread cache utilization (%) = (threads_created / connections) * 100
  • The key buffer can improve the access speed to Moodle's SELECT queries. The correct size depends on the size of the index files (.myi) and in Moodle 1.6 or later (without any additional modules and plugins), the recommendation for this value is key_buffer_size = 32M. Ideally you want the database to be reading once from the disk for every 100 requests so monitor that the value is suitable for your install by adjusting the value of key_buffer_size so that the following formulas are true:
 key_read / key_read_requests < 0.01
 key_write / key_write_requests <= 1.0
  • Set the maximum number of connections so that your users will not see a "Too many connections" message. Be careful that this may have an impact on the total memory used. MySQL connections usually last for milliseconds, so it is unusual even for a heavily loaded server fo this value to be over 200.
  • Manage high burst activity. If your Moodle install uses a lot of quizzes and you are experiencing performance problems (check by monitoring the value of threads_connected - it should not be rising) consider increasing the value of back_log.
  • Optimisez vos tables chaque semaine et après une mise à jour de Moodle. It is good practice to also optimize your tables after performing a large data deletion exercise, e.g. at the end of your semester or academic year. This will ensure that index files are up to date. Backup your database first and then use:
 mysql>CHECK TABLE mdl_tablename;
 mysql>OPTIMIZE TABLE mdl_tablename;
The common tables in Moodle to check are mdl_course_sections, mdl_forum_posts, mdl_log and mdl_sessions (if using dbsessions). Any errors need to be corrected using REPAIR TABLE (see the MySQL manual).
  • Maintain the key distribution. Every month or so it is a good idea to stop the mysql server and run these myisamchk commands.
 #myisamchk -a -S /pathtomysql/data/moodledir/*.MYI
Attention : You must stop the mysql database process (mysqld) before running any myisamchk command. If you do not, you risk data loss.
  • Réduisez le nombre de tables temporaires sauvées sur le disque. Vérifiez cela avec la valeur created_tmp_disk_tables. If this is relatively large (>5%) increase tmp_table_size until you see a reduction. Notez que cela aura un impact sur la RAM utilisée.
  • Les tables de Moodle sont au format MyISAM, donc désactivez InnoDB car il n'y aura pas de gain de performance. Si vous devez utiliser InnoDB, vous devrez convertir toutes vos tables Moodle.

Autres liens de performance de bases de données :

Paramètres d'administration de Moodle

  • 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.
  • Les performances peuvent être grandement améliorées en autorisant l'usage des commandes systèmes zip/unzip/du (plutôt que les librairies PHP) - visitez Administration/Configuration/Paramètres techniques et saisissez le chemin des exécutables concernés.
  • 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.
  • 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 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.
  • L'activité 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.

Voir aussi