MoodleDocs - User contributions [en]

Performance recommendations

2009-10-13T18:10:40Z

Fechevarria: /* MySQL performance */ Update MySQLTuner link.

Location: ''Administration > Server > Performance''

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. When trying to optimize your server, try to focus on the factor which will make the most difference to the user. For example, if you have relatively more users browsing than accessing the database, look to improve the webserver performance.

==Obtain a baseline benchmark==

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.

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

==Scalability==

Moodle's design (with clear separation of application layers) allows for strongly scalable setups. (Please check the list of [[Large installations|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.

'''See also''':
*[[Server cluster]]
*[http://moodle.org/mod/forum/discuss.php?d=4801 Scalability] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=57202 Moodle clustering] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=44470 Software load balancing] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=49986 TCP load balancing] forum dicsussion.

==Hardware configuration==
'''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.
* 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 [http://en.wikipedia.org/wiki/Super_PI 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.
* Check the settings on your '''network card'''. You may get an improvement in performance by increasing the use of buffers and transmit/receive descriptors (balance this with processor and memory overheads) and off-loading TCP checksum calculation onto the card instead of the OS.
* Read this [http://moodle.org/mod/forum/discuss.php?d=68579 Case Study] on a server stress test with 300 users.
* See this [http://elearning.sgu.ac.jp/doc/PT/ accompanying report] on network traffic and server loads.
* See the [[Moodle.org configuration]]
* Also see this SFSU presentation at Educause (using VMWare): [http://www.educause.edu/Resources/AnOpenSourceLMSforaMissionCrit/162843]

==Operating System==
* You can use [http://en.wikipedia.org/wiki/Linux Linux](recommended), Unix-based, Windows or Mac OS X 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. If you have a large number of processors running SMP, you may also want to consider using a highly tuned OS such as [http://en.wikipedia.org/wiki/Solaris_Operating_Environment Solaris].
* Check your own OS and '''vendor specific instructions''' for optimization steps.
** For Linux look at the [http://linuxperf.sourceforge.net/ 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 [http://technet.microsoft.com/ Microsoft TechNet site] for optimization documents.

==Web server performance==

Installing [http://www.mozilla.com/en-US/ Firefox] and the [https://addons.mozilla.org/en-US/firefox/addon/1843 firebug] extension will allow you to watch the time it takes for each page component to load. Also, the [https://addons.mozilla.org/en-US/firefox/addon/5369 Yslow] extension will evaluate your page against Yahoo's [http://www.skrenta.com/2007/05/14_rules_for_fast_web_pages_by_1.html 14 rules] ([http://video.yahoo.com/video/play?vid=1040890 video]) for fast loading websites.

===PHP performance===
* You are strongly recommended to use a '''PHP accelerator''' to ease CPU load, such as [http://pecl.php.net/apc APC], [http://www.php-accelerator.co.uk/ PHPA], [http://trac.lighttpd.net/xcache/ Xcache] or [http://eaccelerator.net/ 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 [http://turckmmcache.exeprod.com/TheManifestoEnglish no longer maintained] and can cause failures with PHP 5).
* Improvements in read/write performance can be improved by putting the cached PHP pages on a [[TMPFS]] filesystem - but remember that you'll lose the cache contents when there is a power failure or the server is rebooted.
* Performance of PHP is better when installed as an '''Apache/IIS ISAPI module''' (rather than a CGI).
* Also check the '''memory_limit''' in php.ini, reduce it to 16M for Moodle version earlier than 1.7 ([http://moodle.org/mod/forum/discuss.php?d=39656 See this forum discussion]). For Moodle 1.7 or later, it is recommended that the value of memory_limit should be 40M. As of [http://www.php.net/ChangeLog-5.php PHP 5.2.1] the default value for the memory_limit directive is 128M.

===Apache performance===
* If you are using Apache on a Windows server, use the build from [http://www.apachelounge.com Apache Lounge] which is reported to have [http://moodle.org/mod/forum/discuss.php?d=93358 performance and stability improvements] compared to the official Apache download. Note that this is an unofficial build, so may not keep up with official releases.
* Set the '''MaxClients''' directive correctly. Use this formula to help (which uses 80% of available memory to leave room for spare):
MaxClients = Total available memory * 80% / Max memory usage of apache process
:Memory usage of apache process is usually 10MB, so a general rule of thumb is to divide your available memory in megabytes by 10 to get the value of MaxClients. To find the max memory usage of apache processes read the value from the shell command:
#ps -ylC httpd --sort:rss

:If you need to increase the value of '''MaxClients''' beyond 256, you will also need to set the '''ServerLimit''' directive.

:'''Warning''': Do not be tempted to set the value of MaxClients higher than your available memory as your server will consume more RAM than available and start to swap to disk.
* Consider reducing the '''number of modules''' that Apache loads in the httpd.conf file to the minumum necessary to reduce the memory needed.
* Use the '''latest version of Apache''' - Apache 2 has an improved memory model 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 setting '''KeepAlive Off''' (do this only if your Moodle pages do not contain links to resources or uploaded images) or 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. A more accurate value for KeepAliveTimeout is obtained by observing how long it takes your users to download a page. After altering any of the KeepAlive variables, monitor your CPU utilization as there may be an additional overhead in initiating more worker processes/threads.
* A warning about the previous performance tip. Microsoft Internet Explorer has a (little) known bug that causes seriously problems with SSL-enabled Apache websites. The issue is that if a web server's KeepAlive timeout is set to less than 60 seconds (say to the default of 15 seconds), MSIE can get confused about whether a keep-alive connection is available or not. As a result, any browser POST requests (which always use a keep-alive if available) will fail to reach the server. This is easily reproduced with postings to the Moodle forums. Using MSIE, connect to an ssl-enabled Moodle site. Write a quick forum post, and submit it when the form has been displayed for between 15 seconds and 60 seconds. You will see a browser error message, and your post content will be lost. In some cases, doing this will even crash the Windows TCP stack on the client machine. ''' So, if your site is SSL-enabled, and you use Apache, you should set the KeepAliveTimeout to at least 60 seconds'''.
* As an alternative to using KeepAlive Off, consider setting-up a '''Reverse Proxy server''' infront of the Moodle server to cache HTML files with images. You can then return Apache to using keep-alives on the Moodle server.
* If you do not use a .htaccess file, set the '''AllowOverride''' variable to AllowOverride None to prevent .htaccess lookups.
* Set '''DirectoryIndex''' correctly so as to avoid content-negotiation. Here's an example from a production server:
DirectoryIndex index.php index.html index.htm
* Unless you are doing development work on the server, set '''ExtendedStatus Off''' and disable mod_info as well as mod_status.
* Leave '''HostnameLookups Off''' (as default) to reduce DNS latency.
* Consider reducing the value of '''TimeOut''' to between 30 to 60 (seconds).
* For the '''Options directive''', avoid Options Multiviews as this performs a directory scan. To reduce disk I/O further use
Options -Indexes FollowSymLinks
*'''Caching''' - Apache can be told to make pages load a lot faster by specifying that the browser should cache some various page elements such as images and reuse them from local memory rather than ask for them again every time a page is requested. How to do this varies slightly between OSes but there are two basic steps:

# Install and enable mod_expires - refer to documentation or man pages
# Add this code to the virtual server config file within the <directory> section for the root directory (or within the .htaccess file if AllowOverrides is On):
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType text/html "access plus 1 seconds"
ExpiresByType image/gif "access plus 1 week"
ExpiresByType image/jpeg "access plus 1 week"
ExpiresByType image/png "access plus 1 week"
ExpiresByType text/css "access plus 1 week"
ExpiresByType text/javascript "access plus 1 week"
ExpiresByType application/x-javascript "access plus 1 week"
ExpiresByType text/xml "access plus 1 seconds"
</IfModule>

The effect is to make everything stay in the cache except HTML and XML, which change dynamically. It's possible to gain a several hundred percent decrease in load times this way. Adjust the cache times according to how often your images etc change.

More info: [http://www.metaskills.net/blog/heuristics/sysadmin/how-to-control-browser-caching-with-apache-2 www.metaskills.net]

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

===Lighttpd performance===
You can increase server performance by using a '''light-weight''' webserver like [http://www.lighttpd.net/ lighttpd] (or [http://nginx.net/ nginx])in combination with PHP in FastCGI-mode. Lighttpd was originally created as a proof-of-concept[http://www.lighttpd.net/story] to address the [http://www.kegel.com/c10k.html C10k problem] and while primarily recommended for memory-limited servers, its design origins and asynchronous-IO model make it a suitable and proven[http://blog.lighttpd.net/articles/2006/12/28/lighttpd-powers-5-alexa-top-250-sites] alternative HTTP server for high-load websites and web apps, including Moodle. See the [[lighttpd | MoodleDocs Lighttpd page]] for additional information, configuration example and links.

Alternatively, both [http://www.lighttpd.net/ lighttpd] and [http://nginx.net/ nginx] are capable of performing as a load-balancer and/or reverse-proxy to alleviate load on back-end servers[http://www.linuxjournal.com/article/10108], providing benefit without requiring an actual software change on existing servers.

==Database performance==

Moodle contains a script which will display some key database performance statistics from the [http://phplens.com/lens/adodb/docs-perf.htm ADOdb performance monitor]. Run the script in your browser as in the following example:

http://www.mymoodle.com/admin/dbperformance.php

Use the data displayed as a guide to tune and improve the performance of your database server.

===MySQL performance===

The following are MySQL specific settings which can be adjusted for better performance in your my.cnf (my.ini in Windows). The file contains a list of settings and their values. To see the current values use these commands
SHOW STATUS;
SHOW VARIABLES;
'''Important''': You must make backups of your database before attempting to change any MySQL server configuration. After any change to the my.cnf, restart mysqld.

If you are able, the [http://mysqltuner.com/ MySQLTuner] tool can be run against your MySQL server and will calculate appropriate configuration values for most of the following settings based on your current load, status and variables automatically.

* Enable the '''query cache''' with
query_cache_type = 1.
For most Moodle installs, set the following:
query_cache_size = 36M
query_cache_min_res_unit = 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
table_cache = 256 #(table_open_cache in MySQL > 5.1.2)
(min), and for Moodle 1.7 set
table_cache = 512 #(table_open_cache in MySQL > 5.1.2)
(min). The table cache is used by all threads (connections), so monitor the value of opened_tables to further adjust - if opened_tables > 3 * table_cache(table_open_cache in MySQL > 5.1.2) then increase table_cache upto your OS limit. Note also that the figure for table_cache will also 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 returned and set table_cache to this value.
mysql>SELECT COUNT(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 for 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.
* '''Optimize your tables weekly and after upgrading 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 [http://dev.mysql.com/doc/refman/5.0/en/repair-table.html MySQL manual] and this [http://moodle.org/mod/forum/discuss.php?d=58208#p279638 forum script]).
* '''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
:'''Warning''': You must stop the mysql database process (mysqld) before running any myisamchk command. If you do not, you risk data loss.
* Reduce the number of '''temporary tables saved to disk'''. Check this with the created_tmp_disk_tables value. If this is relatively large (>5%) increase tmp_table_size until you see a reduction. Note that this will have an impact on RAM usage.
* Moodle's tables are in the MyISAM format, so '''turn InnoDB off''' if you feel there is no performance gain. Add <code>skip-innodb</code> to your <code>my.cnf</code> file. If you must use InnoDB, you'll have to convert all of Moodle's tables. To do this run the innodb script:

http://www.mymoodle.com/admin/innodb.php

:See also [http://moodle.org/mod/forum/discuss.php?d=12961 this forum discussion] which looks at the MyISAM vs InnoDB options.

===PostgreSQL performance===

There are some good papers around on tuning PostgreSQL, and Moodle's case does not seem to be different to the general case.

The first thing to recognise is that if you really need to worry about tuning you should be using a separate machine for the database server. If you are not using a separate machine then the answers to many performance questions are substantially muddied by the memory requirements of the rest of the application.

You should probably '''enable autovacuum''', unless you know what you are doing. Many e-learning sites have predictable periods of low use, so disabling autovacuum and running a specific vacuum at those times can be a good option. Or perhaps leave autovacuum running but do a full vacuum weekly in a quiet period.

Set '''shared_buffers''' to something reasonable. For versions up to 8.1 my testing has shown that peak performance is almost always obtained with buffers < 10000, so if you are using such a version, and have more than 512M of RAM just set shared_buffers to 10,000 (8MB).

The buffer management had a big overhaul in 8.2 and "reasonable" is now a much larger number. I have not conducted performance tests with 8.2, but the recommendations from others are generally that you should now scale shared_buffers much more with memory and may continue to reap benefits even up to values like 100,000 (80MB). Consider using 1-2% of system RAM.

PostgreSQL will also assume that the operating system is caching its files, so setting '''effective_cache_size''' to a reasonable value is also a good idea. A reasonable value will usually be (total RAM - RAM in use by programs). If you are running Linux and leave the system running for a day or two you can look at 'free' and under the 'cached' column you will see what it currently is. Consider taking that number (which is kB) and dividing it by 10 (i.e. allow 20% for other programs cache needs and then divide by 8 to get pages). If you are not using a dedicated database server you will need to decrease that value to account for usage by other programs.

Some other useful parameters that can have positive effects, and the values I would typically set them to on a machine with 4G RAM, are:

work_mem = 10240

That's 10M of RAM to use instead of on-disk sorting and so forth. That can give a big speed increase, but it is per connection and 200 connections * 10M is 2G, so it can theoretically chew up a lot of RAM.

maintenance_work_mem = 163840

That's 160M of RAM which will be used by (e.g.) VACUUM, index rebuild, cluster and so forth. This should only be used periodically and should be freed when those processes exit, so I believe it is well worth while.

max_fsm_pages = 100000
max_fsm_relations = 5000

These are used to hold the free-space map, and if they are too small you will see performance degradation after the database has been operating for some time. The exact numbers to set can be gleaned from the output of VACUUM VERBOSE, which prints the required FSM pages at the end of it's run. The 5x increase seems to be useful for a Moodle installation, from experience.

wal_buffers = 64

These buffers are used for the write-ahead log, and there have been a number of reports on the PostgreSQL mailing lists of improvement from this level of increase.

This is a little out of date now (version 8.0) but still worth a read: http://www.powerpostgresql.com/Docs

And there is lots of good stuff here as well: http://www.varlena.com/varlena/GeneralBits/Tidbits/index.php

''Based on Andrew McMillan's post at [http://moodle.org/mod/forum/discuss.php?d=68558 Tuning PostgreSQL] forum thread.''

===Other database performance links===
* Consider using a '''distributed cacheing system''' like [http://en.wikipedia.org/wiki/Memcached memcached] but note that memcached does not have any security features so it should be used behind a firewall.
* Consider using PostgreSQL. See [[Arguments in favour of PostgreSQL]] and [http://moodle.org/mod/forum/discuss.php?d=49195 how to migrate from MySQL to PostgreSQL] (forum discussion).
* [[Increasing the database connection lifetime | Try increasing the database connection lifetime]]
* [http://dev.mysql.com/doc/refman/5.0/en/server-parameters.html General advice on tuning MySQL parameters] (advice from the MySQL manual)
* [http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/ InnoDB performance optimization] taken from the [http://www.mysqlperformanceblog.com/ MySQL performance blog] site.

==Moodle Admin settings==
* In Moodle 1.7 or later, set the '''Cache type''' for your server: Site Admin -> Server -> Performance -> Cache type. There are several options available.
:*If you do not have eaccelerator or mmemcached installed, choose "internal" (which makes use of the record/internal cache - see the next bullet point).
:* If you have a single server and have compiled '''eaccelerator with shared memory support''', set the cache type to the eaccelerator option.
:* If you have a '''separate memcached server''', set the cache type to memcached and enter a csv list of server IP addresses.
* Enable the '''record/internal cache''': Site Admin -> Server -> Performance -> Record cache = True. Set the maximum amount of memory allocated to the cache in the Int Cache Max box. This will enable a primary cache for database records, without using any database engine cache, e.g. MySQL/PostgreSQL cache. See [http://tracker.moodle.org/browse/MDL-7196 this Tracker entry] for a full discussion.
* 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/Server/Cleanup).
* Performance can be greatly improved by allowing Moodle to use the system '''zip/unzip''' commands (rather than PHP-based zip libraries) - visit Admin/Server/System Paths 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).
* If there are performance problems loading course pages, check the '''Resource module settings'''. The setting resource_filterexternalpages is known to slow-down course pages and should be set to 'No' for better performance.
* Check your '''forum settings'''. To improve performance set forum_trackreadposts = No and forum_usermarksread = Yes (this will impact on the convenience of your users' forum experience). Also consider setting the time of the day when old posts are cleared from the read table (forum_cleanreadtime) to when your site is less busy.

==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 [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. When using the Chat module use the configuration settings to tune for your expected load. Pay particular attention to the ''chat_old_ping'' and ''chat_refresh'' parameters as these can have greatest impact on server load.
* The '''Quiz''' module is known to stretch database performance. Try to optimise your database server by tuning. See [http://moodle.org/mod/forum/discuss.php?d=25616&parent=120770 for a brief report on performance for 55 students simultaneously using quizzes]
** See this Case Study for an extensive server stress test with 300 quiz users.[http://moodle.org/mod/forum/discuss.php?d=68579] And this accompanying report on network traffic and server loads. [http://elearning.sgu.ac.jp/doc/PT/]
* 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 '''Recent activities''' block is consuming to much resources if you have huge number of records <code>mdl_log</code>. this is being tested to optimize the SQL query.

==Moodle Image Optimization==

The base images delivered in the original Moodle distribution package provide unoptimized graphics, most of which can benefit from lossless recompression utilizing [http://optipng.sourceforge.net/ optipng] for PNGs, [http://www.lcdf.org/gifsicle/ gifsicle] for GIFs and [http://www.kokkonen.net/tjko/projects.html jpegoptim] for JPGs. Optimized graphics transfer faster and provide a faster perceived response for clients[http://www.websiteoptimization.com/speed/12/], especially distance learners. The following example will recursively optimize (without any loss of quality) all the graphics and image files included in a base Moodle installation directory on a server with the above commands installed and available.

<pre>
find /example/directory/moodle-1.9 -iname *.png -exec optipng -o7 {} \;
find /example/directory/moodle-1.9 -iname *.gif -exec gifsicle -O2 -b {} \;
find /example/directory/moodle-1.9 -iname *.jpg -exec jpegoptim -p {} \;
</pre>

Both [http://optipng.sourceforge.net/ optipng] and [http://www.lcdf.org/gifsicle/ gifsicle] are provided in the base repositories of most newer Linux distributions; [http://www.kokkonen.net/tjko/projects.html jpegoptim] must be downloaded and installed manually.

==See also==

*[[Performance FAQ]]
*Using Moodle: [http://moodle.org/mod/forum/view.php?f=94 Hardware and Performance] forum

There have been a lot of discussions on moodle.org about performance, here are some of the more interesting and (potentially) useful ones:

* [http://moodle.org/mod/forum/discuss.php?d=83057 Performance woes!]
* [http://moodle.org/mod/forum/discuss.php?d=57028 Performance perspectives - a little script]
* [http://moodle.org/mod/forum/discuss.php?d=88927 Comments on planned server hardware]
* [http://moodle.org/mod/forum/discuss.php?d=102978#p461624 Moodle performance in a pil by Martin Langhoff]
[[Category:Performance]]

[[fr:Performance]]
[[ja:パフォーマンス]]
[[pl:Wydajność]]

Performance recommendations

2009-08-12T18:41:37Z

Fechevarria: /* Moodle Image Optimization */

Location: ''Administration > Server > Performance''

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. When trying to optimize your server, try to focus on the factor which will make the most difference to the user. For example, if you have relatively more users browsing than accessing the database, look to improve the webserver performance.

==Obtain a baseline benchmark==

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.

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

==Scalability==

Moodle's design (with clear separation of application layers) allows for strongly scalable setups. (Please check the list of [[Large installations|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.

'''See also''':
*[[Server cluster]]
*[http://moodle.org/mod/forum/discuss.php?d=4801 Scalability] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=57202 Moodle clustering] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=44470 Software load balancing] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=49986 TCP load balancing] forum dicsussion.

==Hardware configuration==
'''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.
* 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 [http://en.wikipedia.org/wiki/Super_PI 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.
* Check the settings on your '''network card'''. You may get an improvement in performance by increasing the use of buffers and transmit/receive descriptors (balance this with processor and memory overheads) and off-loading TCP checksum calculation onto the card instead of the OS.
* Read this [http://moodle.org/mod/forum/discuss.php?d=68579 Case Study] on a server stress test with 300 users.
* See this [http://elearning.sgu.ac.jp/doc/PT/ accompanying report] on network traffic and server loads.
* See the [[Moodle.org configuration]]
* Also see this SFSU presentation at Educause (using VMWare): [http://www.educause.edu/Resources/AnOpenSourceLMSforaMissionCrit/162843]

==Operating System==
* You can use [http://en.wikipedia.org/wiki/Linux Linux](recommended), Unix-based, Windows or Mac OS X 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. If you have a large number of processors running SMP, you may also want to consider using a highly tuned OS such as [http://en.wikipedia.org/wiki/Solaris_Operating_Environment Solaris].
* Check your own OS and '''vendor specific instructions''' for optimization steps.
** For Linux look at the [http://linuxperf.sourceforge.net/ 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 [http://technet.microsoft.com/ Microsoft TechNet site] for optimization documents.

==Web server performance==

Installing [http://www.mozilla.com/en-US/ Firefox] and the [https://addons.mozilla.org/en-US/firefox/addon/1843 firebug] extension will allow you to watch the time it takes for each page component to load. Also, the [https://addons.mozilla.org/en-US/firefox/addon/5369 Yslow] extension will evaluate your page against Yahoo's [http://www.skrenta.com/2007/05/14_rules_for_fast_web_pages_by_1.html 14 rules] ([http://video.yahoo.com/video/play?vid=1040890 video]) for fast loading websites.

===PHP performance===
* You are strongly recommended to use a '''PHP accelerator''' to ease CPU load, such as [http://pecl.php.net/apc APC], [http://www.php-accelerator.co.uk/ PHPA], [http://trac.lighttpd.net/xcache/ Xcache] or [http://eaccelerator.net/ 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 [http://turckmmcache.exeprod.com/TheManifestoEnglish no longer maintained] and can cause failures with PHP 5).
* Improvements in read/write performance can be improved by putting the cached PHP pages on a [[TMPFS]] filesystem - but remember that you'll lose the cache contents when there is a power failure or the server is rebooted.
* Performance of PHP is better when installed as an '''Apache/IIS ISAPI module''' (rather than a CGI).
* Also check the '''memory_limit''' in php.ini, reduce it to 16M for Moodle version earlier than 1.7 ([http://moodle.org/mod/forum/discuss.php?d=39656 See this forum discussion]). For Moodle 1.7 or later, it is recommended that the value of memory_limit should be 40M. As of [http://www.php.net/ChangeLog-5.php PHP 5.2.1] the default value for the memory_limit directive is 128M.

===Apache performance===
* If you are using Apache on a Windows server, use the build from [http://www.apachelounge.com Apache Lounge] which is reported to have [http://moodle.org/mod/forum/discuss.php?d=93358 performance and stability improvements] compared to the official Apache download. Note that this is an unofficial build, so may not keep up with official releases.
* Set the '''MaxClients''' directive correctly. Use this formula to help (which uses 80% of available memory to leave room for spare):
MaxClients = Total available memory * 80% / Max memory usage of apache process
:Memory usage of apache process is usually 10MB, so a general rule of thumb is to divide your available memory in megabytes by 10 to get the value of MaxClients. To find the max memory usage of apache processes read the value from the shell command:
#ps -ylC httpd --sort:rss

:If you need to increase the value of '''MaxClients''' beyond 256, you will also need to set the '''ServerLimit''' directive.

:'''Warning''': Do not be tempted to set the value of MaxClients higher than your available memory as your server will consume more RAM than available and start to swap to disk.
* Consider reducing the '''number of modules''' that Apache loads in the httpd.conf file to the minumum necessary to reduce the memory needed.
* Use the '''latest version of Apache''' - Apache 2 has an improved memory model 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 setting '''KeepAlive Off''' (do this only if your Moodle pages do not contain links to resources or uploaded images) or 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. A more accurate value for KeepAliveTimeout is obtained by observing how long it takes your users to download a page. After altering any of the KeepAlive variables, monitor your CPU utilization as there may be an additional overhead in initiating more worker processes/threads.
* A warning about the previous performance tip. Microsoft Internet Explorer has a (little) known bug that causes seriously problems with SSL-enabled Apache websites. The issue is that if a web server's KeepAlive timeout is set to less than 60 seconds (say to the default of 15 seconds), MSIE can get confused about whether a keep-alive connection is available or not. As a result, any browser POST requests (which always use a keep-alive if available) will fail to reach the server. This is easily reproduced with postings to the Moodle forums. Using MSIE, connect to an ssl-enabled Moodle site. Write a quick forum post, and submit it when the form has been displayed for between 15 seconds and 60 seconds. You will see a browser error message, and your post content will be lost. In some cases, doing this will even crash the Windows TCP stack on the client machine. ''' So, if your site is SSL-enabled, and you use Apache, you should set the KeepAliveTimeout to at least 60 seconds'''.
* As an alternative to using KeepAlive Off, consider setting-up a '''Reverse Proxy server''' infront of the Moodle server to cache HTML files with images. You can then return Apache to using keep-alives on the Moodle server.
* If you do not use a .htaccess file, set the '''AllowOverride''' variable to AllowOverride None to prevent .htaccess lookups.
* Set '''DirectoryIndex''' correctly so as to avoid content-negotiation. Here's an example from a production server:
DirectoryIndex index.php index.html index.htm
* Unless you are doing development work on the server, set '''ExtendedStatus Off''' and disable mod_info as well as mod_status.
* Leave '''HostnameLookups Off''' (as default) to reduce DNS latency.
* Consider reducing the value of '''TimeOut''' to between 30 to 60 (seconds).
* For the '''Options directive''', avoid Options Multiviews as this performs a directory scan. To reduce disk I/O further use
Options -Indexes FollowSymLinks
*'''Caching''' - Apache can be told to make pages load a lot faster by specifying that the browser should cache some various page elements such as images and reuse them from local memory rather than ask for them again every time a page is requested. How to do this varies slightly between OSes but there are two basic steps:

# Install and enable mod_expires - refer to documentation or man pages
# Add this code to the virtual server config file within the <directory> section for the root directory (or within the .htaccess file if AllowOverrides is On):
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType text/html "access plus 1 seconds"
ExpiresByType image/gif "access plus 1 week"
ExpiresByType image/jpeg "access plus 1 week"
ExpiresByType image/png "access plus 1 week"
ExpiresByType text/css "access plus 1 week"
ExpiresByType text/javascript "access plus 1 week"
ExpiresByType application/x-javascript "access plus 1 week"
ExpiresByType text/xml "access plus 1 seconds"
</IfModule>

The effect is to make everything stay in the cache except HTML and XML, which change dynamically. It's possible to gain a several hundred percent decrease in load times this way. Adjust the cache times according to how often your images etc change.

More info: [http://www.metaskills.net/blog/heuristics/sysadmin/how-to-control-browser-caching-with-apache-2 www.metaskills.net]

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

===Lighttpd performance===
You can increase server performance by using a '''light-weight''' webserver like [http://www.lighttpd.net/ lighttpd] (or [http://nginx.net/ nginx])in combination with PHP in FastCGI-mode. Lighttpd was originally created as a proof-of-concept[http://www.lighttpd.net/story] to address the [http://www.kegel.com/c10k.html C10k problem] and while primarily recommended for memory-limited servers, its design origins and asynchronous-IO model make it a suitable and proven[http://blog.lighttpd.net/articles/2006/12/28/lighttpd-powers-5-alexa-top-250-sites] alternative HTTP server for high-load websites and web apps, including Moodle. See the [[lighttpd | MoodleDocs Lighttpd page]] for additional information, configuration example and links.

Alternatively, both [http://www.lighttpd.net/ lighttpd] and [http://nginx.net/ nginx] are capable of performing as a load-balancer and/or reverse-proxy to alleviate load on back-end servers[http://www.linuxjournal.com/article/10108], providing benefit without requiring an actual software change on existing servers.

==Database performance==

Moodle contains a script which will display some key database performance statistics from the [http://phplens.com/lens/adodb/docs-perf.htm ADOdb performance monitor]. Run the script in your browser as in the following example:

http://www.mymoodle.com/admin/dbperformance.php

Use the data displayed as a guide to tune and improve the performance of your database server.

===MySQL performance===

The following are MySQL specific settings which can be adjusted for better performance in your my.cnf (my.ini in Windows). The file contains a list of settings and their values. To see the current values use these commands
SHOW STATUS;
SHOW VARIABLES;
'''Important''': You must make backups of your database before attempting to change any MySQL server configuration. After any change to the my.cnf, restart mysqld.

If you are able, the [http://wiki.mysqltuner.com/MySQLTuner MySQLTuner] tool can be run against your MySQL server and will calculate appropriate configuration values for most of the following settings based on your current load, status and variables automatically.

* Enable the '''query cache''' with
query_cache_type = 1.
For most Moodle installs, set the following:
query_cache_size = 36M
query_cache_min_res_unit = 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
table_cache = 256 #(table_open_cache in MySQL > 5.1.2)
(min), and for Moodle 1.7 set
table_cache = 512 #(table_open_cache in MySQL > 5.1.2)
(min). The table cache is used by all threads (connections), so monitor the value of opened_tables to further adjust - if opened_tables > 3 * table_cache(table_open_cache in MySQL > 5.1.2) then increase table_cache upto your OS limit. Note also that the figure for table_cache will also 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 returned and set table_cache to this value.
mysql>SELECT COUNT(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 for 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.
* '''Optimize your tables weekly and after upgrading 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 [http://dev.mysql.com/doc/refman/5.0/en/repair-table.html MySQL manual] and this [http://moodle.org/mod/forum/discuss.php?d=58208#p279638 forum script]).
* '''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
:'''Warning''': You must stop the mysql database process (mysqld) before running any myisamchk command. If you do not, you risk data loss.
* Reduce the number of '''temporary tables saved to disk'''. Check this with the created_tmp_disk_tables value. If this is relatively large (>5%) increase tmp_table_size until you see a reduction. Note that this will have an impact on RAM usage.
* Moodle's tables are in the MyISAM format, so '''turn InnoDB off''' if you feel there is no performance gain. Add <code>skip-innodb</code> to your <code>my.cnf</code> file. If you must use InnoDB, you'll have to convert all of Moodle's tables. To do this run the innodb script:

http://www.mymoodle.com/admin/innodb.php

:See also [http://moodle.org/mod/forum/discuss.php?d=12961 this forum discussion] which looks at the MyISAM vs InnoDB options.

===PostgreSQL performance===

There are some good papers around on tuning PostgreSQL, and Moodle's case does not seem to be different to the general case.

The first thing to recognise is that if you really need to worry about tuning you should be using a separate machine for the database server. If you are not using a separate machine then the answers to many performance questions are substantially muddied by the memory requirements of the rest of the application.

You should probably '''enable autovacuum''', unless you know what you are doing. Many e-learning sites have predictable periods of low use, so disabling autovacuum and running a specific vacuum at those times can be a good option. Or perhaps leave autovacuum running but do a full vacuum weekly in a quiet period.

Set '''shared_buffers''' to something reasonable. For versions up to 8.1 my testing has shown that peak performance is almost always obtained with buffers < 10000, so if you are using such a version, and have more than 512M of RAM just set shared_buffers to 10,000 (8MB).

The buffer management had a big overhaul in 8.2 and "reasonable" is now a much larger number. I have not conducted performance tests with 8.2, but the recommendations from others are generally that you should now scale shared_buffers much more with memory and may continue to reap benefits even up to values like 100,000 (80MB). Consider using 1-2% of system RAM.

PostgreSQL will also assume that the operating system is caching its files, so setting '''effective_cache_size''' to a reasonable value is also a good idea. A reasonable value will usually be (total RAM - RAM in use by programs). If you are running Linux and leave the system running for a day or two you can look at 'free' and under the 'cached' column you will see what it currently is. Consider taking that number (which is kB) and dividing it by 10 (i.e. allow 20% for other programs cache needs and then divide by 8 to get pages). If you are not using a dedicated database server you will need to decrease that value to account for usage by other programs.

Some other useful parameters that can have positive effects, and the values I would typically set them to on a machine with 4G RAM, are:

work_mem = 10240

That's 10M of RAM to use instead of on-disk sorting and so forth. That can give a big speed increase, but it is per connection and 200 connections * 10M is 2G, so it can theoretically chew up a lot of RAM.

maintenance_work_mem = 163840

That's 160M of RAM which will be used by (e.g.) VACUUM, index rebuild, cluster and so forth. This should only be used periodically and should be freed when those processes exit, so I believe it is well worth while.

max_fsm_pages = 100000
max_fsm_relations = 5000

These are used to hold the free-space map, and if they are too small you will see performance degradation after the database has been operating for some time. The exact numbers to set can be gleaned from the output of VACUUM VERBOSE, which prints the required FSM pages at the end of it's run. The 5x increase seems to be useful for a Moodle installation, from experience.

wal_buffers = 64

These buffers are used for the write-ahead log, and there have been a number of reports on the PostgreSQL mailing lists of improvement from this level of increase.

This is a little out of date now (version 8.0) but still worth a read: http://www.powerpostgresql.com/Docs

And there is lots of good stuff here as well: http://www.varlena.com/varlena/GeneralBits/Tidbits/index.php

''Based on Andrew McMillan's post at [http://moodle.org/mod/forum/discuss.php?d=68558 Tuning PostgreSQL] forum thread.''

===Other database performance links===
* Consider using a '''distributed cacheing system''' like [http://en.wikipedia.org/wiki/Memcached memcached] but note that memcached does not have any security features so it should be used behind a firewall.
* Consider using PostgreSQL. See [[Arguments in favour of PostgreSQL]] and [http://moodle.org/mod/forum/discuss.php?d=49195 how to migrate from MySQL to PostgreSQL] (forum discussion).
* [[Increasing the database connection lifetime | Try increasing the database connection lifetime]]
* [http://dev.mysql.com/doc/refman/5.0/en/server-parameters.html General advice on tuning MySQL parameters] (advice from the MySQL manual)
* [http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/ InnoDB performance optimization] taken from the [http://www.mysqlperformanceblog.com/ MySQL performance blog] site.

==Moodle Admin settings==
* In Moodle 1.7 or later, set the '''Cache type''' for your server: Site Admin -> Server -> Performance -> Cache type. There are several options available.
:*If you do not have eaccelerator or mmemcached installed, choose "internal" (which makes use of the record/internal cache - see the next bullet point).
:* If you have a single server and have compiled '''eaccelerator with shared memory support''', set the cache type to the eaccelerator option.
:* If you have a '''separate memcached server''', set the cache type to memcached and enter a csv list of server IP addresses.
* Enable the '''record/internal cache''': Site Admin -> Server -> Performance -> Record cache = True. Set the maximum amount of memory allocated to the cache in the Int Cache Max box. This will enable a primary cache for database records, without using any database engine cache, e.g. MySQL/PostgreSQL cache. See [http://tracker.moodle.org/browse/MDL-7196 this Tracker entry] for a full discussion.
* 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/Server/Cleanup).
* Performance can be greatly improved by allowing Moodle to use the system '''zip/unzip''' commands (rather than PHP-based zip libraries) - visit Admin/Server/System Paths 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).
* If there are performance problems loading course pages, check the '''Resource module settings'''. The setting resource_filterexternalpages is known to slow-down course pages and should be set to 'No' for better performance.
* Check your '''forum settings'''. To improve performance set forum_trackreadposts = No and forum_usermarksread = Yes (this will impact on the convenience of your users' forum experience). Also consider setting the time of the day when old posts are cleared from the read table (forum_cleanreadtime) to when your site is less busy.

==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 [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. When using the Chat module use the configuration settings to tune for your expected load. Pay particular attention to the ''chat_old_ping'' and ''chat_refresh'' parameters as these can have greatest impact on server load.
* The '''Quiz''' module is known to stretch database performance. Try to optimise your database server by tuning. See [http://moodle.org/mod/forum/discuss.php?d=25616&parent=120770 for a brief report on performance for 55 students simultaneously using quizzes]
** See this Case Study for an extensive server stress test with 300 quiz users.[http://moodle.org/mod/forum/discuss.php?d=68579] And this accompanying report on network traffic and server loads. [http://elearning.sgu.ac.jp/doc/PT/]
* 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 '''Recent activities''' block is consuming to much resources if you have huge number of records <code>mdl_log</code>. this is being tested to optimize the SQL query.

==Moodle Image Optimization==

The base images delivered in the original Moodle distribution package provide unoptimized graphics, most of which can benefit from lossless recompression utilizing [http://optipng.sourceforge.net/ optipng] for PNGs, [http://www.lcdf.org/gifsicle/ gifsicle] for GIFs and [http://www.kokkonen.net/tjko/projects.html jpegoptim] for JPGs. Optimized graphics transfer faster and provide a faster perceived response for clients[http://www.websiteoptimization.com/speed/12/], especially distance learners. The following example will recursively optimize (without any loss of quality) all the graphics and image files included in a base Moodle installation directory on a server with the above commands installed and available.

<pre>
find /example/directory/moodle-1.9 -iname *.png -exec optipng -o7 {} \;
find /example/directory/moodle-1.9 -iname *.gif -exec gifsicle -O2 -b {} \;
find /example/directory/moodle-1.9 -iname *.jpg -exec jpegoptim -p {} \;
</pre>

Both [http://optipng.sourceforge.net/ optipng] and [http://www.lcdf.org/gifsicle/ gifsicle] are provided in the base repositories of most newer Linux distributions; [http://www.kokkonen.net/tjko/projects.html jpegoptim] must be downloaded and installed manually.

==See also==

*[[Performance FAQ]]
*Using Moodle [http://moodle.org/mod/forum/view.php?f=94 Hardware and Performance forum]

There have been a lot of discussions on moodle.org about performance, here are some of the more interesting and (potentially) useful ones:

* [http://moodle.org/mod/forum/discuss.php?d=83057 Performance woes!]
* [http://moodle.org/mod/forum/discuss.php?d=57028 Performance perspectives - a little script]
* [http://moodle.org/mod/forum/discuss.php?d=88927 Comments on planned server hardware]
* [http://moodle.org/mod/forum/discuss.php?d=102978#p461624 Moodle performance in a pil by Martin Langhoff]
[[Category:Performance]]

[[fr:Performance]]
[[ja:パフォーマンス]]
[[pl:Wydajność]]

Performance recommendations

2009-08-12T18:40:11Z

Fechevarria: /* Lighttpd performance */

Location: ''Administration > Server > Performance''

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. When trying to optimize your server, try to focus on the factor which will make the most difference to the user. For example, if you have relatively more users browsing than accessing the database, look to improve the webserver performance.

==Obtain a baseline benchmark==

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.

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

==Scalability==

Moodle's design (with clear separation of application layers) allows for strongly scalable setups. (Please check the list of [[Large installations|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.

'''See also''':
*[[Server cluster]]
*[http://moodle.org/mod/forum/discuss.php?d=4801 Scalability] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=57202 Moodle clustering] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=44470 Software load balancing] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=49986 TCP load balancing] forum dicsussion.

==Hardware configuration==
'''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.
* 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 [http://en.wikipedia.org/wiki/Super_PI 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.
* Check the settings on your '''network card'''. You may get an improvement in performance by increasing the use of buffers and transmit/receive descriptors (balance this with processor and memory overheads) and off-loading TCP checksum calculation onto the card instead of the OS.
* Read this [http://moodle.org/mod/forum/discuss.php?d=68579 Case Study] on a server stress test with 300 users.
* See this [http://elearning.sgu.ac.jp/doc/PT/ accompanying report] on network traffic and server loads.
* See the [[Moodle.org configuration]]
* Also see this SFSU presentation at Educause (using VMWare): [http://www.educause.edu/Resources/AnOpenSourceLMSforaMissionCrit/162843]

==Operating System==
* You can use [http://en.wikipedia.org/wiki/Linux Linux](recommended), Unix-based, Windows or Mac OS X 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. If you have a large number of processors running SMP, you may also want to consider using a highly tuned OS such as [http://en.wikipedia.org/wiki/Solaris_Operating_Environment Solaris].
* Check your own OS and '''vendor specific instructions''' for optimization steps.
** For Linux look at the [http://linuxperf.sourceforge.net/ 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 [http://technet.microsoft.com/ Microsoft TechNet site] for optimization documents.

==Web server performance==

Installing [http://www.mozilla.com/en-US/ Firefox] and the [https://addons.mozilla.org/en-US/firefox/addon/1843 firebug] extension will allow you to watch the time it takes for each page component to load. Also, the [https://addons.mozilla.org/en-US/firefox/addon/5369 Yslow] extension will evaluate your page against Yahoo's [http://www.skrenta.com/2007/05/14_rules_for_fast_web_pages_by_1.html 14 rules] ([http://video.yahoo.com/video/play?vid=1040890 video]) for fast loading websites.

===PHP performance===
* You are strongly recommended to use a '''PHP accelerator''' to ease CPU load, such as [http://pecl.php.net/apc APC], [http://www.php-accelerator.co.uk/ PHPA], [http://trac.lighttpd.net/xcache/ Xcache] or [http://eaccelerator.net/ 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 [http://turckmmcache.exeprod.com/TheManifestoEnglish no longer maintained] and can cause failures with PHP 5).
* Improvements in read/write performance can be improved by putting the cached PHP pages on a [[TMPFS]] filesystem - but remember that you'll lose the cache contents when there is a power failure or the server is rebooted.
* Performance of PHP is better when installed as an '''Apache/IIS ISAPI module''' (rather than a CGI).
* Also check the '''memory_limit''' in php.ini, reduce it to 16M for Moodle version earlier than 1.7 ([http://moodle.org/mod/forum/discuss.php?d=39656 See this forum discussion]). For Moodle 1.7 or later, it is recommended that the value of memory_limit should be 40M. As of [http://www.php.net/ChangeLog-5.php PHP 5.2.1] the default value for the memory_limit directive is 128M.

===Apache performance===
* If you are using Apache on a Windows server, use the build from [http://www.apachelounge.com Apache Lounge] which is reported to have [http://moodle.org/mod/forum/discuss.php?d=93358 performance and stability improvements] compared to the official Apache download. Note that this is an unofficial build, so may not keep up with official releases.
* Set the '''MaxClients''' directive correctly. Use this formula to help (which uses 80% of available memory to leave room for spare):
MaxClients = Total available memory * 80% / Max memory usage of apache process
:Memory usage of apache process is usually 10MB, so a general rule of thumb is to divide your available memory in megabytes by 10 to get the value of MaxClients. To find the max memory usage of apache processes read the value from the shell command:
#ps -ylC httpd --sort:rss

:If you need to increase the value of '''MaxClients''' beyond 256, you will also need to set the '''ServerLimit''' directive.

:'''Warning''': Do not be tempted to set the value of MaxClients higher than your available memory as your server will consume more RAM than available and start to swap to disk.
* Consider reducing the '''number of modules''' that Apache loads in the httpd.conf file to the minumum necessary to reduce the memory needed.
* Use the '''latest version of Apache''' - Apache 2 has an improved memory model 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 setting '''KeepAlive Off''' (do this only if your Moodle pages do not contain links to resources or uploaded images) or 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. A more accurate value for KeepAliveTimeout is obtained by observing how long it takes your users to download a page. After altering any of the KeepAlive variables, monitor your CPU utilization as there may be an additional overhead in initiating more worker processes/threads.
* A warning about the previous performance tip. Microsoft Internet Explorer has a (little) known bug that causes seriously problems with SSL-enabled Apache websites. The issue is that if a web server's KeepAlive timeout is set to less than 60 seconds (say to the default of 15 seconds), MSIE can get confused about whether a keep-alive connection is available or not. As a result, any browser POST requests (which always use a keep-alive if available) will fail to reach the server. This is easily reproduced with postings to the Moodle forums. Using MSIE, connect to an ssl-enabled Moodle site. Write a quick forum post, and submit it when the form has been displayed for between 15 seconds and 60 seconds. You will see a browser error message, and your post content will be lost. In some cases, doing this will even crash the Windows TCP stack on the client machine. ''' So, if your site is SSL-enabled, and you use Apache, you should set the KeepAliveTimeout to at least 60 seconds'''.
* As an alternative to using KeepAlive Off, consider setting-up a '''Reverse Proxy server''' infront of the Moodle server to cache HTML files with images. You can then return Apache to using keep-alives on the Moodle server.
* If you do not use a .htaccess file, set the '''AllowOverride''' variable to AllowOverride None to prevent .htaccess lookups.
* Set '''DirectoryIndex''' correctly so as to avoid content-negotiation. Here's an example from a production server:
DirectoryIndex index.php index.html index.htm
* Unless you are doing development work on the server, set '''ExtendedStatus Off''' and disable mod_info as well as mod_status.
* Leave '''HostnameLookups Off''' (as default) to reduce DNS latency.
* Consider reducing the value of '''TimeOut''' to between 30 to 60 (seconds).
* For the '''Options directive''', avoid Options Multiviews as this performs a directory scan. To reduce disk I/O further use
Options -Indexes FollowSymLinks
*'''Caching''' - Apache can be told to make pages load a lot faster by specifying that the browser should cache some various page elements such as images and reuse them from local memory rather than ask for them again every time a page is requested. How to do this varies slightly between OSes but there are two basic steps:

# Install and enable mod_expires - refer to documentation or man pages
# Add this code to the virtual server config file within the <directory> section for the root directory (or within the .htaccess file if AllowOverrides is On):
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType text/html "access plus 1 seconds"
ExpiresByType image/gif "access plus 1 week"
ExpiresByType image/jpeg "access plus 1 week"
ExpiresByType image/png "access plus 1 week"
ExpiresByType text/css "access plus 1 week"
ExpiresByType text/javascript "access plus 1 week"
ExpiresByType application/x-javascript "access plus 1 week"
ExpiresByType text/xml "access plus 1 seconds"
</IfModule>

The effect is to make everything stay in the cache except HTML and XML, which change dynamically. It's possible to gain a several hundred percent decrease in load times this way. Adjust the cache times according to how often your images etc change.

More info: [http://www.metaskills.net/blog/heuristics/sysadmin/how-to-control-browser-caching-with-apache-2 www.metaskills.net]

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

===Lighttpd performance===
You can increase server performance by using a '''light-weight''' webserver like [http://www.lighttpd.net/ lighttpd] (or [http://nginx.net/ nginx])in combination with PHP in FastCGI-mode. Lighttpd was originally created as a proof-of-concept[http://www.lighttpd.net/story] to address the [http://www.kegel.com/c10k.html C10k problem] and while primarily recommended for memory-limited servers, its design origins and asynchronous-IO model make it a suitable and proven[http://blog.lighttpd.net/articles/2006/12/28/lighttpd-powers-5-alexa-top-250-sites] alternative HTTP server for high-load websites and web apps, including Moodle. See the [[lighttpd | MoodleDocs Lighttpd page]] for additional information, configuration example and links.

Alternatively, both [http://www.lighttpd.net/ lighttpd] and [http://nginx.net/ nginx] are capable of performing as a load-balancer and/or reverse-proxy to alleviate load on back-end servers[http://www.linuxjournal.com/article/10108], providing benefit without requiring an actual software change on existing servers.

==Database performance==

Moodle contains a script which will display some key database performance statistics from the [http://phplens.com/lens/adodb/docs-perf.htm ADOdb performance monitor]. Run the script in your browser as in the following example:

http://www.mymoodle.com/admin/dbperformance.php

Use the data displayed as a guide to tune and improve the performance of your database server.

===MySQL performance===

The following are MySQL specific settings which can be adjusted for better performance in your my.cnf (my.ini in Windows). The file contains a list of settings and their values. To see the current values use these commands
SHOW STATUS;
SHOW VARIABLES;
'''Important''': You must make backups of your database before attempting to change any MySQL server configuration. After any change to the my.cnf, restart mysqld.

If you are able, the [http://wiki.mysqltuner.com/MySQLTuner MySQLTuner] tool can be run against your MySQL server and will calculate appropriate configuration values for most of the following settings based on your current load, status and variables automatically.

* Enable the '''query cache''' with
query_cache_type = 1.
For most Moodle installs, set the following:
query_cache_size = 36M
query_cache_min_res_unit = 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
table_cache = 256 #(table_open_cache in MySQL > 5.1.2)
(min), and for Moodle 1.7 set
table_cache = 512 #(table_open_cache in MySQL > 5.1.2)
(min). The table cache is used by all threads (connections), so monitor the value of opened_tables to further adjust - if opened_tables > 3 * table_cache(table_open_cache in MySQL > 5.1.2) then increase table_cache upto your OS limit. Note also that the figure for table_cache will also 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 returned and set table_cache to this value.
mysql>SELECT COUNT(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 for 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.
* '''Optimize your tables weekly and after upgrading 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 [http://dev.mysql.com/doc/refman/5.0/en/repair-table.html MySQL manual] and this [http://moodle.org/mod/forum/discuss.php?d=58208#p279638 forum script]).
* '''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
:'''Warning''': You must stop the mysql database process (mysqld) before running any myisamchk command. If you do not, you risk data loss.
* Reduce the number of '''temporary tables saved to disk'''. Check this with the created_tmp_disk_tables value. If this is relatively large (>5%) increase tmp_table_size until you see a reduction. Note that this will have an impact on RAM usage.
* Moodle's tables are in the MyISAM format, so '''turn InnoDB off''' if you feel there is no performance gain. Add <code>skip-innodb</code> to your <code>my.cnf</code> file. If you must use InnoDB, you'll have to convert all of Moodle's tables. To do this run the innodb script:

http://www.mymoodle.com/admin/innodb.php

:See also [http://moodle.org/mod/forum/discuss.php?d=12961 this forum discussion] which looks at the MyISAM vs InnoDB options.

===PostgreSQL performance===

There are some good papers around on tuning PostgreSQL, and Moodle's case does not seem to be different to the general case.

The first thing to recognise is that if you really need to worry about tuning you should be using a separate machine for the database server. If you are not using a separate machine then the answers to many performance questions are substantially muddied by the memory requirements of the rest of the application.

You should probably '''enable autovacuum''', unless you know what you are doing. Many e-learning sites have predictable periods of low use, so disabling autovacuum and running a specific vacuum at those times can be a good option. Or perhaps leave autovacuum running but do a full vacuum weekly in a quiet period.

Set '''shared_buffers''' to something reasonable. For versions up to 8.1 my testing has shown that peak performance is almost always obtained with buffers < 10000, so if you are using such a version, and have more than 512M of RAM just set shared_buffers to 10,000 (8MB).

The buffer management had a big overhaul in 8.2 and "reasonable" is now a much larger number. I have not conducted performance tests with 8.2, but the recommendations from others are generally that you should now scale shared_buffers much more with memory and may continue to reap benefits even up to values like 100,000 (80MB). Consider using 1-2% of system RAM.

PostgreSQL will also assume that the operating system is caching its files, so setting '''effective_cache_size''' to a reasonable value is also a good idea. A reasonable value will usually be (total RAM - RAM in use by programs). If you are running Linux and leave the system running for a day or two you can look at 'free' and under the 'cached' column you will see what it currently is. Consider taking that number (which is kB) and dividing it by 10 (i.e. allow 20% for other programs cache needs and then divide by 8 to get pages). If you are not using a dedicated database server you will need to decrease that value to account for usage by other programs.

Some other useful parameters that can have positive effects, and the values I would typically set them to on a machine with 4G RAM, are:

work_mem = 10240

That's 10M of RAM to use instead of on-disk sorting and so forth. That can give a big speed increase, but it is per connection and 200 connections * 10M is 2G, so it can theoretically chew up a lot of RAM.

maintenance_work_mem = 163840

That's 160M of RAM which will be used by (e.g.) VACUUM, index rebuild, cluster and so forth. This should only be used periodically and should be freed when those processes exit, so I believe it is well worth while.

max_fsm_pages = 100000
max_fsm_relations = 5000

These are used to hold the free-space map, and if they are too small you will see performance degradation after the database has been operating for some time. The exact numbers to set can be gleaned from the output of VACUUM VERBOSE, which prints the required FSM pages at the end of it's run. The 5x increase seems to be useful for a Moodle installation, from experience.

wal_buffers = 64

These buffers are used for the write-ahead log, and there have been a number of reports on the PostgreSQL mailing lists of improvement from this level of increase.

This is a little out of date now (version 8.0) but still worth a read: http://www.powerpostgresql.com/Docs

And there is lots of good stuff here as well: http://www.varlena.com/varlena/GeneralBits/Tidbits/index.php

''Based on Andrew McMillan's post at [http://moodle.org/mod/forum/discuss.php?d=68558 Tuning PostgreSQL] forum thread.''

===Other database performance links===
* Consider using a '''distributed cacheing system''' like [http://en.wikipedia.org/wiki/Memcached memcached] but note that memcached does not have any security features so it should be used behind a firewall.
* Consider using PostgreSQL. See [[Arguments in favour of PostgreSQL]] and [http://moodle.org/mod/forum/discuss.php?d=49195 how to migrate from MySQL to PostgreSQL] (forum discussion).
* [[Increasing the database connection lifetime | Try increasing the database connection lifetime]]
* [http://dev.mysql.com/doc/refman/5.0/en/server-parameters.html General advice on tuning MySQL parameters] (advice from the MySQL manual)
* [http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/ InnoDB performance optimization] taken from the [http://www.mysqlperformanceblog.com/ MySQL performance blog] site.

==Moodle Admin settings==
* In Moodle 1.7 or later, set the '''Cache type''' for your server: Site Admin -> Server -> Performance -> Cache type. There are several options available.
:*If you do not have eaccelerator or mmemcached installed, choose "internal" (which makes use of the record/internal cache - see the next bullet point).
:* If you have a single server and have compiled '''eaccelerator with shared memory support''', set the cache type to the eaccelerator option.
:* If you have a '''separate memcached server''', set the cache type to memcached and enter a csv list of server IP addresses.
* Enable the '''record/internal cache''': Site Admin -> Server -> Performance -> Record cache = True. Set the maximum amount of memory allocated to the cache in the Int Cache Max box. This will enable a primary cache for database records, without using any database engine cache, e.g. MySQL/PostgreSQL cache. See [http://tracker.moodle.org/browse/MDL-7196 this Tracker entry] for a full discussion.
* 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/Server/Cleanup).
* Performance can be greatly improved by allowing Moodle to use the system '''zip/unzip''' commands (rather than PHP-based zip libraries) - visit Admin/Server/System Paths 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).
* If there are performance problems loading course pages, check the '''Resource module settings'''. The setting resource_filterexternalpages is known to slow-down course pages and should be set to 'No' for better performance.
* Check your '''forum settings'''. To improve performance set forum_trackreadposts = No and forum_usermarksread = Yes (this will impact on the convenience of your users' forum experience). Also consider setting the time of the day when old posts are cleared from the read table (forum_cleanreadtime) to when your site is less busy.

==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 [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. When using the Chat module use the configuration settings to tune for your expected load. Pay particular attention to the ''chat_old_ping'' and ''chat_refresh'' parameters as these can have greatest impact on server load.
* The '''Quiz''' module is known to stretch database performance. Try to optimise your database server by tuning. See [http://moodle.org/mod/forum/discuss.php?d=25616&parent=120770 for a brief report on performance for 55 students simultaneously using quizzes]
** See this Case Study for an extensive server stress test with 300 quiz users.[http://moodle.org/mod/forum/discuss.php?d=68579] And this accompanying report on network traffic and server loads. [http://elearning.sgu.ac.jp/doc/PT/]
* 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 '''Recent activities''' block is consuming to much resources if you have huge number of records <code>mdl_log</code>. this is being tested to optimize the SQL query.

==Moodle Image Optimization==

The base images delivered in the original Moodle distribution package provide unoptimized graphics, most of which can benefit from lossless recompression utilizing [http://optipng.sourceforge.net/ optipng] for PNGs, [http://www.lcdf.org/gifsicle/ gifsicle] for GIFs and [http://www.kokkonen.net/tjko/projects.html jpegoptim] for JPGs. Optimized graphics transfer faster and provide a faster perceived response for clients[http://www.websiteoptimization.com/speed/12/], especially distance learners. The following example will recursively optimize (without any loss of quality) all the graphics and image files included in a base Moodle installation directory on a server with the above commands installed and available.

<pre>
find /example/directory/moodle-1.9 -iname '*.png' -exec optipng -o7 {} \;
find /example/directory/moodle-1.9 -iname '*.gif' -exec gifsicle -O2 -b {} \;
find /example/directory/moodle-1.9 -iname '*.jpg' -exec jpegoptim -p {} \;
</pre>

Both [http://optipng.sourceforge.net/ optipng] and [http://www.lcdf.org/gifsicle/ gifsicle] are provided in the base repositories of most newer Linux distributions; [http://www.kokkonen.net/tjko/projects.html jpegoptim] must be downloaded and installed manually.

==See also==

*[[Performance FAQ]]
*Using Moodle [http://moodle.org/mod/forum/view.php?f=94 Hardware and Performance forum]

There have been a lot of discussions on moodle.org about performance, here are some of the more interesting and (potentially) useful ones:

* [http://moodle.org/mod/forum/discuss.php?d=83057 Performance woes!]
* [http://moodle.org/mod/forum/discuss.php?d=57028 Performance perspectives - a little script]
* [http://moodle.org/mod/forum/discuss.php?d=88927 Comments on planned server hardware]
* [http://moodle.org/mod/forum/discuss.php?d=102978#p461624 Moodle performance in a pil by Martin Langhoff]
[[Category:Performance]]

[[fr:Performance]]
[[ja:パフォーマンス]]
[[pl:Wydajność]]

lighttpd

2009-08-11T19:15:07Z

Fechevarria: updated to recent Fedora in combination with Moodle 1.9.x requirements

[http://www.lighttpd.net/ Lighttpd] (a.k.a. Lighty) is a lightweight webserver with a small memory footprint that works well with PHP accelerators like [http://eaccelerator.net/ eAccelerator] and [http://us2.php.net/apc Alternative PHP Cache (APC)]. It is an alternative to Apache and IIS particularly well suited to systems with low resources, especially RAM -- ideal when using virtual private server (VPS) hosting services. Even on hosts with plenty of resources, Lighty is as fast as Apache if not faster and worth considering.

Lighttpd meets all the base requirements for Moodle and provides most common webserving features; however, it is not intended to replace Apache feature for feature. If your needs extend further than Moodle, be aware of lighttpd's differences and limitations as well as level of knowledge and support necessary and available. Be certain it meets all of your needs before deploying in a production environment.

Installation varies according to platform, if the following example doesn't apply to your server configuration, check the official instruction page [http://trac.lighttpd.net/trac/wiki/TutorialInstallation here]. You will also need to install PHP (preferably with an accelerator) and FastCGI according to [http://trac.lighttpd.net/trac/wiki/TutorialLighttpdAndPHP these] instructions.

===Fedora 9, 10 & 11 Example===
Lighttpd is a part of the official repository and can be installed using yum to meet all of Moodle's base requirements, including the PHP accelerator [http://us2.php.net/apc Alternative PHP Cache (APC)], using the following command.
<pre>
yum install lighttpd lighttpd-fastcgi mysql php php-mysql \
php-pecl-apc php-gd php-mbstring php-xmlrpc php-pdo ;
</pre>
Under the respective sections, edit /etc/lighttpd/lighttpd.conf to point to the Moodle root directory, uncomment the FastCGI module and the ''fastcgi module'' section; be sure the ''bin-path'' points to the PHP FastCGI executable:
<pre>
## modules to load
# NOTE: a comma (,) is necessary when other active modules follow this one,
# unnecessary when this is the final active module in the server.modules directive
"mod_fastcgi",
## a static document-root example
server.document-root = "/home/moodle-1.9/"
#### fastcgi module
fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => "/tmp/php-fastcgi.socket",
"bin-path" => "/usr/bin/php-cgi"
)
)
)
</pre>
Client cache control and expiry is very flexible, uncomment the expiration module directive and add the following into /etc/lighttpd/lighttpd.conf for expiry control of common types of static files, change the number of days to meet your needs.
<pre>
## modules to load
# Module load order is important, the mod_expire should be listed before mod_compress when both are active.
# NOTE: a comma (,) is necessary when other active modules follow this one,
# unnecessary when this is the final active module in the server.modules directive
"mod_expire",
## Client cache control section.
# mod_expire - image files expire 2 days after first access
$HTTP["url"] =~ "\.(gif|GIF|jpg|JPG|png|PNG|swf|SWF|ico|ICO)$" {
expire.url = ( "" => "access 2 days" )
}
# mod_expire - includes expire 1 day after first access
$HTTP["url"] =~ "\.(css|CSS|js|JS)$" {
expire.url = ( "" => "access 1 days" )
}
# Some versions of lighttpd may require the following directives for full functionality, uncomment if needed.
# etag.use-inode = "enable"
# etag.use-mtime = "enable"
# etag.use-size = "enable"
# static-file.etags = "enable"
</pre>
Since Moodle maintains its own logs and reporting tools, you can disable lighttpd's server-level logging by commenting out the following lines in /etc/lighttpd/lighttpd.conf, as follows under the respective sections.
<pre>
## modules to load
# NOTE: a comma (,) is necessary when other active modules follow this one,
# unnecessary when this is the final active module in the server.modules directive
# "mod_accesslog"
#### accesslog module
#accesslog.filename = "/var/log/lighttpd/access_log"
</pre>
If your server has CPU cycles to spare, enabling compression improves network speed and students' perceived response time, especially for off-campus and distance learners. Compression should be separated at the HTTP and PHP levels to maximize CPU cycles (especially on multiple-CPU and multi-core systems). First uncomment the compression module in /etc/lighttpd/lighttpd.conf, create a directory for the compressed file temporary store (in this example, it's /tmp/compress.tmp) and enter it along with the types of files to compress (do not include PHP mimetypes here), as follows under the respective sections:
<pre>
## modules to load
# NOTE: a comma (,) is necessary when other active modules follow this one,
# unnecessary when this is the final active module in the server.modules directive
"mod_compress"
#### compress module
compress.cache-dir = "/tmp/compress.tmp/"
compress.filetype = ("text/plain", "text/javascript", "text/css", "text/xml")
</pre>
Second, edit /etc/php.ini to enable compression on the PHP output and consider increasing the maximum server submission size (individual courses can still be limited lower than and up to this limit within Moodle itself, if needed).
<pre>
zlib.output_compression = On
post_max_size = 32M
</pre>
Finally, the standard memory pool setting of 32MB for [http://us2.php.net/apc Alternative PHP Cache (APC)] is fairly low for Moodle, edit /etc/php.d/apc.ini and increase it to 64 or 128 depending on server load and total available memory. Increasing this setting can increase the speed of page generation made from within the opcode cache on even modest equipment.
<pre>
apc.shm_size=128
</pre>

==See Also==
* [http://tracker.moodle.org/browse/MDL-14638 Networking issue related to lighttpd]
* [http://en.wlmp-project.net/downloads.php WLMP project downloads for Windows packages]
* [http://moodle.org/mod/forum/discuss.php?d=126176 Debian/Ubuntu configuration, performance comparison vs apache2]

lighttpd

2009-02-13T20:29:11Z

Fechevarria: /* Fedora 6, 7, 8 & 9 Example */

[http://www.lighttpd.net/ Lighttpd] (a.k.a. Lighty) is a lightweight webserver with a small memory footprint that works well with PHP accelerators like [http://eaccelerator.net/ eAccelerator] and [http://us2.php.net/apc Alternative PHP Cache (APC)]. It is an alternative to Apache and IIS particularly well suited to systems with low resources, especially RAM -- ideal when using virtual private server (VPS) hosting services. Even on hosts with plenty of resources, Lighty is as fast as Apache if not faster and worth considering.

Lighttpd meets all the base requirements for Moodle and provides most common webserving features; however, it is not intended to replace Apache feature for feature. If your needs extend further than Moodle, be aware of lighttpd's differences and limitations as well as level of knowledge and support necessary and available. Be certain it meets all of your needs before deploying in a production environment.

Installation varies according to platform, so if the following example doesn't apply to your server configuration, check the official instruction page [http://trac.lighttpd.net/trac/wiki/TutorialInstallation here]. You will also need to install PHP (preferrably with an accelerator) and FastCGI according to [http://trac.lighttpd.net/trac/wiki/TutorialLighttpdAndPHP these] instructions.

===Fedora 6, 7, 8 & 9 Example===
On the latest versions of Fedora, lighttpd is a part of the official repository and can be installed using yum to meet all of Moodle's base requirements, including the PHP accelerator [http://us2.php.net/apc Alternative PHP Cache (APC)], using the following command.
<pre>
yum install lighttpd lighttpd-fastcgi mysql php php-mysql \
php-pecl-apc php-gd php-mbstring php-xmlrpc php-pdo ;
</pre>
Under the respective sections, edit /etc/lighttpd/lighttpd.conf to point to the Moodle root directory, uncomment the FastCGI module and the ''fastcgi module'' section; be sure the ''bin-path'' points to the PHP FastCGI executable:
<pre>
## modules to load
# NOTE: a comma (,) is necessary when other active modules follow this one,
# unnecessary when this is the final active module in the server.modules directive
"mod_fastcgi",
## a static document-root example
server.document-root = "/home/moodle-1.9/"
#### fastcgi module
fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => "/tmp/php-fastcgi.socket",
"bin-path" => "/usr/bin/php-cgi"
)
)
)
</pre>
Client cache control and expiry is very flexible, uncomment the expiration module directive and add the following into /etc/lighttpd/lighttpd.conf for expiry control of common types of static files, change the number of days to meet your needs.
<pre>
## modules to load
# Module load order is important, the mod_expire should be listed before mod_compress when both are active.
# NOTE: a comma (,) is necessary when other active modules follow this one,
# unnecessary when this is the final active module in the server.modules directive
"mod_expire",
## Client cache control section.
# mod_expire - image files expire 2 days after first access
$HTTP["url"] =~ "\.(gif|GIF|jpg|JPG|png|PNG|swf|SWF|ico|ICO)$" {
expire.url = ( "" => "access 2 days" )
}
# mod_expire - includes expire 1 day after first access
$HTTP["url"] =~ "\.(css|CSS|js|JS)$" {
expire.url = ( "" => "access 1 days" )
}
# Some versions of lighttpd may require the following directives for full functionality, uncomment if needed.
# etag.use-inode = "enable"
# etag.use-mtime = "enable"
# etag.use-size = "enable"
# static-file.etags = "enable"
</pre>
Since Moodle maintains its own logs and reporting tools, you can disable lighttpd's server-level logging by commenting out the following lines in /etc/lighttpd/lighttpd.conf, as follows under the respective sections.
<pre>
## modules to load
# NOTE: a comma (,) is necessary when other active modules follow this one,
# unnecessary when this is the final active module in the server.modules directive
# "mod_accesslog"
#### accesslog module
#accesslog.filename = "/var/log/lighttpd/access_log"
</pre>
If your server has CPU cycles to spare, enabling compression improves network speed and students' perceived response time, especially for off-campus and distance learners. Compression should be separated at the HTTP and PHP levels to maximize CPU cycles (especially on multiple-CPU or multi-core systems). First uncomment the compression module in /etc/lighttpd/lighttpd.conf, create a directory for the compressed file temporary store (in this example, it's /home/compress.tmp) and enter it along with the types of files to compress (do not include PHP mimetypes here), as follows under the respective sections:
<pre>
## modules to load
# NOTE: a comma (,) is necessary when other active modules follow this one,
# unnecessary when this is the final active module in the server.modules directive
"mod_compress"
#### compress module
compress.cache-dir = "/home/compress.tmp/"
compress.filetype = ("text/plain", "text/javascript", "text/css", "text/xml")
</pre>
Second, edit /etc/php.ini to enable compression on the PHP output and consider increasing the maximum server submission size (individual courses can still be limited lower than and up to this limit within Moodle itself, if needed).
<pre>
zlib.output_compression = On
post_max_size = 32M
</pre>
Finally, the standard memory pool setting of 32MB for [http://us2.php.net/apc Alternative PHP Cache (APC)] is fairly low for Moodle, edit /etc/php.d/apc.ini and increase it to 48 or 64 depending on server load and total available memory. This setting alone can shave 300ms off each page generation made from within the opcode cache.
<pre>
apc.shm_size=64
</pre>

==See Also==
* [http://tracker.moodle.org/browse/MDL-14638 Networking issue related to lighttpd]
* [http://en.wlmp-project.net/downloads.php WLMP project downloads for Windows packages]

lighttpd

2009-01-29T18:30:36Z

Fechevarria: /* Fedora 6, 7, 8 & 9 Example */

[http://www.lighttpd.net/ Lighttpd] (a.k.a. Lighty) is a lightweight webserver with a small memory footprint that works well with PHP accelerators like [http://eaccelerator.net/ eAccelerator] and [http://us2.php.net/apc Alternative PHP Cache (APC)]. It is an alternative to Apache and IIS particularly well suited to systems with low resources, especially RAM -- ideal when using virtual private server (VPS) hosting services. Even on hosts with plenty of resources, Lighty is as fast as Apache if not faster and worth considering.

Lighttpd meets all the base requirements for Moodle and provides most common webserving features; however, it is not intended to replace Apache feature for feature. If your needs extend further than Moodle, be aware of lighttpd's differences and limitations as well as level of knowledge and support necessary and available. Be certain it meets all of your needs before deploying in a production environment.

Installation varies according to platform, so if the following example doesn't apply to your server configuration, check the official instruction page [http://trac.lighttpd.net/trac/wiki/TutorialInstallation here]. You will also need to install PHP (preferrably with an accelerator) and FastCGI according to [http://trac.lighttpd.net/trac/wiki/TutorialLighttpdAndPHP these] instructions.

===Fedora 6, 7, 8 & 9 Example===
On the latest versions of Fedora, lighttpd is a part of the official repository and can be installed using yum to meet all of Moodle's base requirements, including the PHP accelerator [http://us2.php.net/apc Alternative PHP Cache (APC)], using the following command.
<pre>
yum install lighttpd lighttpd-fastcgi mysql php php-mysql \
php-pecl-apc php-gd php-mbstring php-xmlrpc php-pdo ;
</pre>
Under the respective sections, edit /etc/lighttpd/lighttpd.conf to point to the Moodle root directory, uncomment the FastCGI module and the ''fastcgi module'' section; be sure the ''bin-path'' points to the PHP FastCGI executable:
<pre>
## modules to load
# NOTE: a comma (,) is necessary when other active modules follow this one,
# unnecessary when this is the final active module in the server.modules directive
"mod_fastcgi",
## a static document-root example
server.document-root = "/home/moodle-1.9/"
#### fastcgi module
fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => "/tmp/php-fastcgi.socket",
"bin-path" => "/usr/bin/php-cgi"
)
)
)
</pre>
Client cache control and expiry is very flexible, uncomment the expiration module directive and add the following into /etc/lighttpd/lighttpd.conf for expiry control of common types of static files, change the number of days to meet your needs.
<pre>
## modules to load
# Module load order is important, the mod_expire should be listed before mod_compress when both are active.
# NOTE: a comma (,) is necessary when other active modules follow this one,
# unnecessary when this is the final active module in the server.modules directive
"mod_expire",
## Client cache control section.
# mod_expire - image files expire 2 days after first access
$HTTP["url"] =~ "\.(gif|GIF|jpg|JPG|png|PNG|swf|SWF|ico|ICO)$" {
expire.url = ( "" => "access 2 days" )
}
# mod_expire - includes expire 1 day after first access
$HTTP["url"] =~ "\.(css|CSS|js|JS)$" {
expire.url = ( "" => "access 1 days" )
}
# Some versions of lighttpd may require the following directives for full functionality, uncomment if needed.
# etag.use-inode = "enable"
# etag.use-mtime = "enable"
# etag.use-size = "enable"
# static-file.etags = "enable"
</pre>
Since Moodle maintains its own logs and reporting tools, you can disable lighttpd's server-level logging by commenting out the following lines in /etc/lighttpd/lighttpd.conf, as follows under the respective sections.
<pre>
## modules to load
# NOTE: a comma (,) is necessary when other active modules follow this one,
# unnecessary when this is the final active module in the server.modules directive
# "mod_accesslog"
#### accesslog module
#accesslog.filename = "/var/log/lighttpd/access_log"
</pre>
If your server has CPU cycles to spare, enabling compression improves network speed and students' perceived response time, especially for off-campus and distance learners. Compression should be separated at the HTTP and PHP levels to maximize CPU cycles (especially on multiple-CPU or multi-core systems). First uncomment the compression module in /etc/lighttpd/lighttpd.conf, create a directory for the compressed file temporary store (in this example, it's /home/compress.tmp) and enter it along with the types of files to compress (do not include PHP mimetypes here), as follows under the respective sections:
<pre>
## modules to load
# NOTE: a comma (,) is necessary when other active modules follow this one,
# unnecessary when this is the final active module in the server.modules directive
"mod_compress"
#### compress module
compress.cache-dir = "/home/compress.tmp/"
compress.filetype = ("text/plain", "text/javascript", "text/css", "text/xml")
</pre>
Second, edit /etc/php.ini to enable compression on the PHP output and consider increasing the maximum server submission size (individual courses can still be limited lower than and up to this limit within Moodle itself, if needed).
<pre>
zlib.output_compression = On
post_max_size = 32M
</pre>

==See Also==
* [http://tracker.moodle.org/browse/MDL-14638 Networking issue related to lighttpd]
* [http://en.wlmp-project.net/downloads.php WLMP project downloads for Windows packages]

lighttpd

2009-01-29T18:26:02Z

Fechevarria:

[http://www.lighttpd.net/ Lighttpd] (a.k.a. Lighty) is a lightweight webserver with a small memory footprint that works well with PHP accelerators like [http://eaccelerator.net/ eAccelerator] and [http://us2.php.net/apc Alternative PHP Cache (APC)]. It is an alternative to Apache and IIS particularly well suited to systems with low resources, especially RAM -- ideal when using virtual private server (VPS) hosting services. Even on hosts with plenty of resources, Lighty is as fast as Apache if not faster and worth considering.

Lighttpd meets all the base requirements for Moodle and provides most common webserving features; however, it is not intended to replace Apache feature for feature. If your needs extend further than Moodle, be aware of lighttpd's differences and limitations as well as level of knowledge and support necessary and available. Be certain it meets all of your needs before deploying in a production environment.

Installation varies according to platform, so if the following example doesn't apply to your server configuration, check the official instruction page [http://trac.lighttpd.net/trac/wiki/TutorialInstallation here]. You will also need to install PHP (preferrably with an accelerator) and FastCGI according to [http://trac.lighttpd.net/trac/wiki/TutorialLighttpdAndPHP these] instructions.

===Fedora 6, 7, 8 & 9 Example===
On the latest versions of Fedora, lighttpd is a part of the official repository and can be installed using yum to meet all of Moodle's base requirements, including the PHP accelerator [http://us2.php.net/apc Alternative PHP Cache (APC)], using the following command.
<pre>
yum install lighttpd lighttpd-fastcgi mysql php php-mysql \
php-pecl-apc php-gd php-mbstring php-xmlrpc php-pdo ;
</pre>
Under the respective sections, edit /etc/lighttpd/lighttpd.conf to point to the Moodle root directory, uncomment the FastCGI module and in the ''fastcgi module'' section, be sure the ''bin-path'' points to the PHP FastCGI executable:
<pre>
## modules to load
"mod_fastcgi",
## a static document-root example
server.document-root = "/home/moodle-1.9/"
#### fastcgi module
fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => "/tmp/php-fastcgi.socket",
"bin-path" => "/usr/bin/php-cgi"
)
)
)
</pre>
Client cache control and expiry is very flexible, uncomment the expiration module directive and add the following into /etc/lighttpd/lighttpd.conf for expiry control of common types of static files, change the number of days to meet your needs.
<pre>
## modules to load
# Module load order is important, the mod_expire should be listed before mod_compress when both are active.
"mod_expire"
## Client cache control section.
# mod_expire - image files expire 2 days after first access
$HTTP["url"] =~ "\.(gif|GIF|jpg|JPG|png|PNG|swf|SWF|ico|ICO)$" {
expire.url = ( "" => "access 2 days" )
}
# mod_expire - includes expire 1 day after first access
$HTTP["url"] =~ "\.(css|CSS|js|JS)$" {
expire.url = ( "" => "access 1 days" )
}
# Some versions of lighttpd may require the following directives for full functionality, uncomment if needed.
# etag.use-inode = "enable"
# etag.use-mtime = "enable"
# etag.use-size = "enable"
# static-file.etags = "enable"
</pre>
Since Moodle maintains its own logs and reporting tools, you can disable lighttpd's server-level logging by commenting out the following lines in /etc/lighttpd/lighttpd.conf, as follows under the respective sections.
<pre>
## modules to load
# "mod_accesslog"
#### accesslog module
#accesslog.filename = "/var/log/lighttpd/access_log"
</pre>
If your server has CPU cycles to spare, enabling compression improves network speed and students' perceived response time, especially for off-campus and distance learners. Compression should be separated at the HTTP and PHP levels to maximize CPU cycles (especially on multiple-CPU or multi-core systems). First uncomment the compression module in /etc/lighttpd/lighttpd.conf, create a directory for the compressed file temporary store (in this example, it's /home/compress.tmp) and enter it along with the types of files to compress (do not include PHP mimetypes here), as follows under the respective sections:
<pre>
## modules to load
# NOTE: a comma (,) is necessary when other active modules follow this one,
# unnecessary when this is the final active module in the server.modules directive
"mod_compress" #,
#### compress module
compress.cache-dir = "/home/compress.tmp/"
compress.filetype = ("text/plain", "text/javascript", "text/css", "text/xml")
</pre>
Second, edit /etc/php.ini to enable compression on the PHP output and consider increasing the maximum server submission size (individual courses can still be limited lower than and up to this limit within Moodle itself, if needed).
<pre>
zlib.output_compression = On
post_max_size = 32M
</pre>

==See Also==
* [http://tracker.moodle.org/browse/MDL-14638 Networking issue related to lighttpd]
* [http://en.wlmp-project.net/downloads.php WLMP project downloads for Windows packages]

lighttpd

2009-01-25T19:03:14Z

Fechevarria: /* Fedora 6, 7, 8 & 9 Example */

[http://www.lighttpd.net/ Lighttpd] (a.k.a. Lighty) is a lightweight webserver with a small memory footprint that works well with PHP accelerators like [http://eaccelerator.net/ eAccelerator] and [http://us2.php.net/apc Alternative PHP Cache (APC)]. It is an alternative to Apache and IIS particularly well suited to systems with low resources, especially RAM -- ideal when using virtual private server (VPS) hosting services. Even on hosts with plenty of resources, Lighty is as fast as Apache if not faster and worth considering.

Note Lighttpd meets all the base requirements for Moodle and provides most of the common webserving features; however, it is not intended to replace Apache feature for feature. If your needs extend further than Moodle, be aware of lighttpd's differences and limitations as well as level of knowledge and support necessary and available. You are encouraged to be certain it meets all of your needs before deploying in a production environment.

Installation varies according to platform, so if the following example doesn't apply to your server configuration, check the official instruction page [http://trac.lighttpd.net/trac/wiki/TutorialInstallation here]. You will also need to install php (preferrably with an accelerator) and fast-cgi according to [http://trac.lighttpd.net/trac/wiki/TutorialLighttpdAndPHP these] instructions.

A notable difference between Lighttpd and Apache is the expires directive that controls the caching of content. Apache allows you to set the expiry by file type, e.g. making a jpg image stay in the browser cache for a week, older versions of Lighttpd specify folders to be cached. Versions with ''ETag generation'' support provide full expiry mechanisms and control.

===Fedora 6, 7, 8 & 9 Example===
On the latest versions of Fedora, lighttpd is a part of the official repository and can be installed using yum to meet all of Moodle's base requirements, including the PHP accelerator [http://us2.php.net/apc Alternative PHP Cache (APC)], using the following command.
<pre>
yum install lighttpd lighttpd-fastcgi mysql php php-mysql \
php-pecl-apc php-gd php-mbstring php-xmlrpc php-pdo ;
</pre>
Edit /etc/lighttpd/lighttpd.conf to point to the Moodle root directory and the ''PHP-CGI'' area to activate and point to PHP's fastcgi executable, under the respective sections:
<pre>
## a static document-root example
server.document-root = "/home/moodle-1.9/"
#### fastcgi module
fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => "/tmp/php-fastcgi.socket",
"bin-path" => "/usr/bin/php-cgi"
)
)
)
</pre>
Client cache control and expiry is very flexible, uncomment the expiration module directive and add the following into /etc/lighttpd/lighttpd.conf for expiry control of common types of static files.
<pre>
## modules to load
# Module load order is important, the mod_expire should be listed before mod_compress when both are active.
"mod_expire"
## Client cache control section.
# mod_expire - image files expire 2 days after first access
$HTTP["url"] =~ "\.(gif|GIF|jpg|JPG|png|PNG|swf|SWF|ico|ICO)$" {
expire.url = ( "" => "access 2 days" )
}
# mod_expire - includes expire 1 day after first access
$HTTP["url"] =~ "\.(css|CSS|js|JS)$" {
expire.url = ( "" => "access 1 days" )
}
# Some versions of lighttpd may require the following directives for full functionality, uncomment if needed.
# etag.use-inode = "enable"
# etag.use-mtime = "enable"
# etag.use-size = "enable"
# static-file.etags = "enable"
</pre>
Since Moodle maintains its own logs and reporting tools, you can disable lighttpd's server-level logging by commenting out the following lines in /etc/lighttpd/lighttpd.conf, as follows under the respective sections.
<pre>
## modules to load
# "mod_accesslog"
#### accesslog module
#accesslog.filename = "/var/log/lighttpd/access_log"
</pre>
If your server has CPU cycles to spare, enabling compression improves network speed and students' perceived response time, especially for off-campus and distance learners. Compression should be separated at the HTTP and PHP levels to maximize CPU cycles (especially on multiple-CPU or multi-core systems). First uncomment the compression module in /etc/lighttpd/lighttpd.conf, create a directory for the compressed file temporary store (in this example, it's /home/compress.tmp) and enter it along with the types of files to compress (do not include PHP mimetypes here), as follows under the respective sections:
<pre>
## modules to load
# NOTE: a comma (,) is necessary when other active modules follow this one,
# unnecessary when this is the final active module in the server.modules directive
"mod_compress" #,
#### compress module
compress.cache-dir = "/home/compress.tmp/"
compress.filetype = ("text/plain", "text/javascript", "text/css", "text/xml")
</pre>
Second, edit /etc/php.ini to enable compression on the PHP output and consider increasing the maximum server submission size (individual courses can still be limited lower than and up to this limit within Moodle itself, if needed).
<pre>
zlib.output_compression = On
post_max_size = 32M
</pre>

==See Also==
* [http://tracker.moodle.org/browse/MDL-14638 Networking issue related to lighttpd]
* [http://en.wlmp-project.net/downloads.php WLMP project downloads for Windows packages]

Performance recommendations

2009-01-23T00:40:15Z

Fechevarria: /* See also */

Location: ''Administration > Server > Performance''

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. When trying to optimize your server, try to focus on the factor which will make the most difference to the user. For example, if you have relatively more users browsing than accessing the database, look to improve the webserver performance.

==Obtain a baseline benchmark==

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.

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

==Scalability==

Moodle's design (with clear separation of application layers) allows for strongly scalable setups. (Please check the list of [[Large installations|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.

'''See also''':
*[http://moodle.org/mod/forum/discuss.php?d=4801 Scalability] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=57202 Moodle clustering] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=44470 Software load balancing] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=49986 TCP load balancing] forum dicsussion.

==Hardware configuration==
'''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.
* 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 [http://en.wikipedia.org/wiki/Super_PI 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.
* Check the settings on your '''network card'''. You may get an improvement in performance by increasing the use of buffers and transmit/receive descriptors (balance this with processor and memory overheads) and off-loading TCP checksum calculation onto the card instead of the OS.
* Read this [http://moodle.org/mod/forum/discuss.php?d=68579 Case Study] on a server stress test with 300 users.
* See this [http://elearning.sgu.ac.jp/doc/PT/ accompanying report] on network traffic and server loads.

==Operating System==
* You can use [http://en.wikipedia.org/wiki/Linux Linux](recommended), Unix-based, Windows or Mac OS X 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. If you have a large number of processors running SMP, you may also want to consider using a highly tuned OS such as [http://en.wikipedia.org/wiki/Solaris_Operating_Environment Solaris].
* Check your own OS and '''vendor specific instructions''' for optimization steps.
** For Linux look at the [http://linuxperf.sourceforge.net/ 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 [http://technet.microsoft.com/ Microsoft TechNet site] for optimization documents.

==Web server performance==

Installing [http://www.mozilla.com/en-US/ Firefox] and the [https://addons.mozilla.org/en-US/firefox/addon/1843 firebug] extension will allow you to watch the time it takes for each page component to load. Also, the [https://addons.mozilla.org/en-US/firefox/addon/5369 Yslow] extension will evaluate your page against Yahoo's [http://www.skrenta.com/2007/05/14_rules_for_fast_web_pages_by_1.html 14 rules] ([http://video.yahoo.com/video/play?vid=1040890 video]) for fast loading websites.

===PHP performance===
* You are strongly recommended to use a '''PHP accelerator''' to ease CPU load, such as [http://pecl.php.net/apc APC], [http://www.php-accelerator.co.uk/ PHPA], [http://trac.lighttpd.net/xcache/ Xcache] or [http://eaccelerator.net/ 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 [http://turckmmcache.exeprod.com/TheManifestoEnglish no longer maintained] and can cause failures with PHP 5).
* Improvements in read/write performance can be improved by putting the cached PHP pages on a [[TMPFS]] filesystem - but remember that you'll lose the cache contents when there is a power failure or the server is rebooted.
* Performance of PHP is better when installed as an '''Apache/IIS ISAPI module''' (rather than a CGI).
* Also check the '''memory_limit''' in php.ini, reduce it to 16M for Moodle version earlier than 1.7 ([http://moodle.org/mod/forum/discuss.php?d=39656 See this forum discussion]). For Moodle 1.7 or later, it is recommended that the value of memory_limit should be 40M. As of [http://www.php.net/ChangeLog-5.php PHP 5.2.1] the default value for the memory_limit directive is 128M.

===Apache performance===
* If you are using Apache on a Windows server, use the build from [http://www.apachelounge.com Apache Lounge] which is reported to have [http://moodle.org/mod/forum/discuss.php?d=93358 performance and stability improvements] compared to the official Apache download. Note that this is an unofficial build, so may not keep up with official releases.
* Set the '''MaxClients''' directive correctly. Use this formula to help (which uses 80% of available memory to leave room for spare):
MaxClients = Total available memory * 80% / Max memory usage of apache process
:Memory usage of apache process is usually 10MB, so a general rule of thumb is to divide your available memory in megabytes by 10 to get the value of MaxClients. To find the max memory usage of apache processes read the value from the shell command:
#ps -ylC httpd --sort:rss

:If you need to increase the value of '''MaxClients''' beyond 256, you will also need to set the '''ServerLimit''' directive.

:'''Warning''': Do not be tempted to set the value of MaxClients higher than your available memory as your server will consume more RAM than available and start to swap to disk.
* Consider reducing the '''number of modules''' that Apache loads in the httpd.conf file to the minumum necessary to reduce the memory needed.
* Use the '''latest version of Apache''' - Apache 2 has an improved memory model 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 setting '''KeepAlive Off''' (do this only if your Moodle pages do not contain links to resources or uploaded images) or 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. A more accurate value for KeepAliveTimeout is obtained by observing how long it takes your users to download a page. After altering any of the KeepAlive variables, monitor your CPU utilization as there may be an additional overhead in initiating more worker processes/threads.
* As an alternative to using KeepAlive Off, consider setting-up a '''Reverse Proxy server''' infront of the Moodle server to cache HTML files with images. You can then return Apache to using keep-alives on the Moodle server.
* If you do not use a .htaccess file, set the '''AllowOverride''' variable to AllowOverride None to prevent .htaccess lookups.
* Set '''DirectoryIndex''' correctly so as to avoid content-negotiation. Here's an example from a production server:
DirectoryIndex index.php index.html index.htm
* Unless you are doing development work on the server, set '''ExtendedStatus Off''' and disable mod_info as well as mod_status.
* Leave '''HostnameLookups Off''' (as default) to reduce DNS latency.
* Consider reducing the value of '''TimeOut''' to between 30 to 60 (seconds).
* For the '''Options directive''', avoid Options Multiviews as this performs a directory scan. To reduce disk I/O further use
Options -Indexes FollowSymLinks
*'''Caching''' - Apache can be told to make pages load a lot faster by specifying that the browser should cache some various page elements such as images and reuse them from local memory rather than ask for them again every time a page is requested. How to do this varies slightly between OSes but there are two basic steps:

# Install and enable mod_expires - refer to documentation or man pages
# Add this code to the virtual server config file within the <directory> section for the root directory (or within the .htaccess file if AllowOverrides is On):
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType text/html "access plus 1 seconds"
ExpiresByType image/gif "access plus 1 week"
ExpiresByType image/jpeg "access plus 1 week"
ExpiresByType image/png "access plus 1 week"
ExpiresByType text/css "access plus 1 week"
ExpiresByType text/javascript "access plus 1 week"
ExpiresByType application/x-javascript "access plus 1 week"
ExpiresByType text/xml "access plus 1 seconds"
</IfModule>

The effect is to make everything stay in the cache except HTML and XML, which change dynamically. It's possible to gain a several hundred percent decrease in load times this way. Adjust the cache times according to how often your images etc change.

More info: [http://www.metaskills.net/blog/heuristics/sysadmin/how-to-control-browser-caching-with-apache-2 www.metaskills.net]

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

===Lighttpd performance===
You can increase web server performance by using the '''light-weight webserver''' [http://www.lighttpd.net/ lighttpd] in combination with PHP in fastCGI-mode. Lighttpd has a lower memory consumption than Apache - typically 10M for each process. See this [[lighttpd | MoodleDocs Lighttpd page]] for configuration and administration links.

==Database performance==

Moodle contains a script which will display some key database performance statistics from the [http://phplens.com/lens/adodb/docs-perf.htm ADOdb performance monitor]. Run the script in your browser as in the following example:

http://www.mymoodle.com/admin/dbperformance.php

Use the data displayed as a guide to tune and improve the performance of your database server.

===MySQL performance===

The following are MySQL specific settings which can be adjusted for better performance in your my.cnf (my.ini in Windows). The file contains a list of settings and their values. To see the current values use these commands
SHOW STATUS;
SHOW VARIABLES;
'''Important''': You must make backups of your database before attempting to change any MySQL server configuration. After any change to the my.cnf, restart mysqld.

If you are able, the [http://wiki.mysqltuner.com/MySQLTuner MySQLTuner] tool can be run against your MySQL server and will calculate appropriate configuration values for most of the following settings based on your current load, status and variables automatically.

* Enable the '''query cache''' with
query_cache_type = 1.
For most Moodle installs, set the following:
query_cache_size = 36M
query_cache_min_res_unit = 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
table_cache = 256
(min), and for Moodle 1.7 set
table_cache = 512
(min). The table cache is used by all threads (connections), so monitor the value of opened_tables to further adjust - if opened_tables > 3 * table_cache then increase table_cache upto your OS limit. Note also that the figure for table_cache will also 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 returned and set table_cache to this value.
mysql>SELECT COUNT(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 for 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.
* '''Optimize your tables weekly and after upgrading 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 [http://dev.mysql.com/doc/refman/5.0/en/repair-table.html MySQL manual] and this [http://moodle.org/mod/forum/discuss.php?d=58208#p279638 forum script]).
* '''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
:'''Warning''': You must stop the mysql database process (mysqld) before running any myisamchk command. If you do not, you risk data loss.
* Reduce the number of '''temporary tables saved to disk'''. Check this with the created_tmp_disk_tables value. If this is relatively large (>5%) increase tmp_table_size until you see a reduction. Note that this will have an impact on RAM usage.
* Moodle's tables are in the MyISAM format, so '''turn InnoDB off''' as there is no performance gain. Add <code>skip-innodb</code> to your <code>my.cnf</code> file. If you must use InnoDB, you'll have to convert all of Moodle's tables. To do this run the innodb script:

http://www.mymoodle.com/admin/innodb.php

:See also [http://moodle.org/mod/forum/discuss.php?d=12961 this forum discussion] which looks at the MyISAM vs InnoDB options.

===PostgreSQL performance===

There are some good papers around on tuning PostgreSQL, and Moodle's case does not seem to be different to the general case.

The first thing to recognise is that if you really need to worry about tuning you should be using a separate machine for the database server. If you are not using a separate machine then the answers to many performance questions are substantially muddied by the memory requirements of the rest of the application.

You should probably '''enable autovacuum''', unless you know what you are doing. Many e-learning sites have predictable periods of low use, so disabling autovacuum and running a specific vacuum at those times can be a good option. Or perhaps leave autovacuum running but do a full vacuum weekly in a quiet period.

Set '''shared_buffers''' to something reasonable. For versions up to 8.1 my testing has shown that peak performance is almost always obtained with buffers < 10000, so if you are using such a version, and have more than 512M of RAM just set shared_buffers to 10,000 (8MB).

The buffer management had a big overhaul in 8.2 and "reasonable" is now a much larger number. I have not conducted performance tests with 8.2, but the recommendations from others are generally that you should now scale shared_buffers much more with memory and may continue to reap benefits even up to values like 100,000 (80MB). Consider using 1-2% of system RAM.

PostgreSQL will also assume that the operating system is caching its files, so setting '''effective_cache_size''' to a reasonable value is also a good idea. A reasonable value will usually be (total RAM - RAM in use by programs). If you are running Linux and leave the system running for a day or two you can look at 'free' and under the 'cached' column you will see what it currently is. Consider taking that number (which is kB) and dividing it by 10 (i.e. allow 20% for other programs cache needs and then divide by 8 to get pages). If you are not using a dedicated database server you will need to decrease that value to account for usage by other programs.

Some other useful parameters that can have positive effects, and the values I would typically set them to on a machine with 4G RAM, are:

work_mem = 10240

That's 10M of RAM to use instead of on-disk sorting and so forth. That can give a big speed increase, but it is per connection and 200 connections * 10M is 2G, so it can theoretically chew up a lot of RAM.

maintenance_work_mem = 163840

That's 160M of RAM which will be used by (e.g.) VACUUM, index rebuild, cluster and so forth. This should only be used periodically and should be freed when those processes exit, so I believe it is well worth while.

max_fsm_pages = 100000
max_fsm_relations = 5000

These are used to hold the free-space map, and if they are too small you will see performance degradation after the database has been operating for some time. The exact numbers to set can be gleaned from the output of VACUUM VERBOSE, which prints the required FSM pages at the end of it's run. The 5x increase seems to be useful for a Moodle installation, from experience.

wal_buffers = 64

These buffers are used for the write-ahead log, and there have been a number of reports on the PostgreSQL mailing lists of improvement from this level of increase.

This is a little out of date now (version 8.0) but still worth a read: http://www.powerpostgresql.com/Docs

And there is lots of good stuff here as well: http://www.varlena.com/varlena/GeneralBits/Tidbits/index.php

''Based on Andrew McMillan's post at [http://moodle.org/mod/forum/discuss.php?d=68558 Tuning PostgreSQL] forum thread.''

===Other database performance links===
* Consider using a '''distributed cacheing system''' like [http://en.wikipedia.org/wiki/Memcached memcached] but note that memcached does not have any security features so it should be used behind a firewall.
* Consider using PostgreSQL. See [[Arguments in favour of PostgreSQL]] and [http://moodle.org/mod/forum/discuss.php?d=49195 how to migrate from MySQL to PostgreSQL] (forum discussion).
* [[Increasing the database connection lifetime | Try increasing the database connection lifetime]]
* [http://dev.mysql.com/doc/refman/5.0/en/server-parameters.html General advice on tuning MySQL parameters] (advice from the MySQL manual)
* [http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/ InnoDB performance optimization] taken from the [http://www.mysqlperformanceblog.com/ MySQL performance blog] site.

==Moodle Admin settings==
* In Moodle 1.7 or later, set the '''Cache type''' for your server: Site Admin -> Server -> Performance -> Cache type. There are several options available.
:*If you do not have eaccelerator or mmemcached installed, choose "internal" (which makes use of the record/internal cache - see the next bullet point).
:* If you have a single server and have compiled '''eaccelerator with shared memory support''', set the cache type to the eaccelerator option.
:* If you have a '''separate memcached server''', set the cache type to memcached and enter a csv list of server IP addresses.
* Enable the '''record/internal cache''': Site Admin -> Server -> Performance -> Record cache = True. Set the maximum amount of memory allocated to the cache in the Int Cache Max box. This will enable a primary cache for database records, without using any database engine cache, e.g. MySQL/PostgreSQL cache. See [http://tracker.moodle.org/browse/MDL-7196 this Tracker entry] for a full discussion.
* 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/Server/Cleanup).
* Performance can be greatly improved by allowing Moodle to use the system '''zip/unzip''' commands (rather than PHP-based zip libraries) - visit Admin/Server/System Paths 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).
* If there are performance problems loading course pages, check the '''Resource module settings'''. The setting resource_filterexternalpages is known to slow-down course pages and should be set to 'No' for better performance.
* Check your '''forum settings'''. To improve performance set forum_trackreadposts = No and forum_usermarksread = Yes (this will impact on the convenience of your users' forum experience). Also consider setting the time of the day when old posts are cleared from the read table (forum_cleanreadtime) to when your site is less busy.

==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 [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. When using the Chat module use the configuration settings to tune for your expected load. Pay particular attention to the ''chat_old_ping'' and ''chat_refresh'' parameters as these can have greatest impact on server load.
* The '''Quiz''' module is known to stretch database performance. Try to optimise your database server by tuning. See [http://moodle.org/mod/forum/discuss.php?d=25616&parent=120770 for a brief report on performance for 55 students simultaneously using quizzes]
** See this Case Study for an extensive server stress test with 300 quiz users.[http://moodle.org/mod/forum/discuss.php?d=68579] And this accompanying report on network traffic and server loads. [http://elearning.sgu.ac.jp/doc/PT/]
* 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 '''Recent activities''' block is consuming to much resources if you hvae huge number of records <code>mdl_log</code>. this is being tested to optimize the SQL query.

==Moodle Image Optimization==

The base images delivered in the original Moodle distribution package provide unoptimized graphics, most of which can benefit from lossless recompression utilizing [http://optipng.sourceforge.net/ optipng] for PNGs, [http://www.lcdf.org/gifsicle/ gifsicle] for GIFs and [http://www.kokkonen.net/tjko/projects.html jpegoptim] for JPGs. Optimized graphics transfer faster and provide a faster perceived response for clients[http://www.websiteoptimization.com/speed/12/], especially distance learners. The following example will recursively optimize (without any loss of quality) all the graphics and image files included in a base Moodle installation directory on a server with the above commands installed and available.

<pre>
find /example/directory/moodle-1.9 -iname '*.png' -exec optipng -o7 {} \;
find /example/directory/moodle-1.9 -iname '*.gif' -exec gifsicle -O2 -b {} \;
find /example/directory/moodle-1.9 -iname '*.jpg' -exec jpegoptim -p {} \;
</pre>

Both [http://optipng.sourceforge.net/ optipng] and [http://www.lcdf.org/gifsicle/ gifsicle] are provided in the base repositories of most newer Linux distributions; [http://www.kokkonen.net/tjko/projects.html jpegoptim] must be downloaded and installed manually.

==See also==

*[[Performance FAQ]]
*Using Moodle [http://moodle.org/mod/forum/view.php?f=94 Hardware and Performance forum]

There have been a lot of discussions on moodle.org about performance, here are some of the more interesting and (potentially) useful ones:

* [http://moodle.org/mod/forum/discuss.php?d=83057 Performance woes!]
* [http://moodle.org/mod/forum/discuss.php?d=57028 Performance perspectives - a little script]
* [http://moodle.org/mod/forum/discuss.php?d=88927 Comments on planned server hardware]
* [http://moodle.org/mod/forum/discuss.php?d=102978#p461624 Moodle performance in a pil by Martin Langhoff]
[[Category:Performance]]

[[fr:Performance]]
[[ja:パフォーマンス]]
[[pl:Wydajność]]

lighttpd

2009-01-21T03:01:26Z

Fechevarria:

[http://www.lighttpd.net/ Lighttpd] (a.k.a. Lighty) is a lightweight webserver with a small memory footprint that works well with PHP accelerators like [http://eaccelerator.net/ eAccelerator] and [http://us2.php.net/apc Alternative PHP Cache (APC)]. It is an alternative to Apache and IIS particularly well suited to systems with low resources, especially RAM -- ideal when using virtual private server (VPS) hosting services. Even on hosts with plenty of resources, Lighty is as fast as Apache if not faster and worth considering.

Note Lighttpd meets all the base requirements for Moodle and provides most of the common webserving features; however, it is not intended to replace Apache feature for feature. If your needs extend further than Moodle, be aware of lighttpd's differences and limitations as well as level of knowledge and support necessary and available. You are encouraged to be certain it meets all of your needs before deploying in a production environment.

Installation varies according to platform, so if the following example doesn't apply to your server configuration, check the official instruction page [http://trac.lighttpd.net/trac/wiki/TutorialInstallation here]. You will also need to install php (preferrably with an accelerator) and fast-cgi according to [http://trac.lighttpd.net/trac/wiki/TutorialLighttpdAndPHP these] instructions.

A notable difference between Lighttpd and Apache is the expires directive that controls the caching of content. Apache allows you to set the expiry by file type, e.g. making a jpg image stay in the browser cache for a week, older versions of Lighttpd specify folders to be cached. Versions with ''ETag generation'' support provide full expiry mechanisms and control.

===Fedora 6, 7, 8 & 9 Example===
On the latest versions of Fedora, lighttpd is a part of the official repository and can be installed using yum to meet all of Moodle's base requirements, including the PHP accelerator [http://us2.php.net/apc Alternative PHP Cache (APC)], using the following command.
<pre>
yum install lighttpd lighttpd-fastcgi mysql php php-mysql \
php-pecl-apc php-gd php-mbstring php-xmlrpc php-pdo ;
</pre>
Edit /etc/lighttpd/lighttpd.conf to point to the Moodle root directory and the ''PHP-CGI'' area to activate and point to PHP's fastcgi executable, under the respective sections:
<pre>
## a static document-root example
server.document-root = "/home/moodle-1.9/"
#### fastcgi module
fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => "/tmp/php-fastcgi.socket",
"bin-path" => "/usr/bin/php-cgi"
)
)
)
</pre>
Since Moodle maintains its own logs and reporting tools, you can disable lighttpd's server-level logging by commenting out (put a # mark in front of) the following lines in /etc/lighttpd/lighttpd.conf, as follows under the respective sections.
<pre>
## modules to load
# "mod_accesslog"
#### accesslog module
#accesslog.filename = "/var/log/lighttpd/access_log"
</pre>
If your server has CPU cycles to spare, enabling compression improves network speed and the student's perceived response time, especially for off-campus and distance learners. Compression should be separated at the HTTP and PHP levels to maximize CPU cycles (especially on multiple-CPU or multi-core systems). First uncomment the compression module in /etc/lighttpd/lighttpd.conf, create a directory for the compressed file temporary store (in this example, it's /home/compress.tmp) and enter it along with the types of files to compress (do not include PHP mimetypes here), as follows under the respective sections:
<pre>
## modules to load
# NOTE: a comma (,) is necessary when other active modules follow this one,
# unnecessary when this is the final active module in the server.modules directive
"mod_compress" #,
#### compress module
compress.cache-dir = "/home/compress.tmp/"
compress.filetype = ("text/plain", "text/javascript", "text/css", "text/xml")
</pre>
Second, edit /etc/php.ini to enable compression on the PHP output and consider increasing the maximum server submission size (individual courses can still be limited lower than and up to this limit within Moodle itself, if needed).
<pre>
zlib.output_compression = On
post_max_size = 32M
</pre>
==See Also==
* [http://tracker.moodle.org/browse/MDL-14638 Networking issue related to lighttpd]
* [http://en.wlmp-project.net/downloads.php WLMP project downloads for Windows packages]

lighttpd

2009-01-21T02:51:38Z

Fechevarria: Lighttpd is stable and robust. This page does not need disclaimer after disclaimer. We've run Moodle 1.6 through 1.9 on lighttpd since 2006; replacing all Apache installations--both simple and complex

[http://www.lighttpd.net/ Lighttpd] (a.k.a. Lighty) is a lightweight webserver with a small memory footprint that works well with PHP accelerators like [http://eaccelerator.net/ eAccelerator] and [http://us2.php.net/apc Alternative PHP Cache (APC)]. It is an alternative to Apache and IIS particularly well suited to systems with low resources, especially RAM -- ideal when using virtual private server (VPS) hosting services. Even on hosts with plenty of resources, Lighty is as fast as Apache if not faster and worth considering.

Note that while Lighttpd meets all the base requirements for Moodle and provides most of the common webserving features; however, it is not intended to replace Apache feature for feature. If your needs extend further than Moodle, be aware of lighttpd's differences and limitations as well as level of knowledge and support necessary and available. You are encouraged to be certain it meets all of your needs before deploying in a production environment.

Installation varies according to platform, so if the following example doesn't apply to your server configuration, check the official instruction page [http://trac.lighttpd.net/trac/wiki/TutorialInstallation here]. You will also need to install php (preferrably with an accelerator) and fast-cgi according to [http://trac.lighttpd.net/trac/wiki/TutorialLighttpdAndPHP these] instructions.

A notable difference between Lighttpd and Apache is the expires directive that controls the caching of content. Apache allows you to set the expiry by file type, e.g. making a jpg image stay in the browser cache for a week, older versions of Lighttpd specify folders to be cached. Versions with ''ETag generation'' support provide full expiry mechanisms and control.

===Fedora 6, 7, 8 & 9 Example===
On the latest versions of Fedora, lighttpd is a part of the official repository and can be installed using yum to meet all of Moodle's base requirements, including the PHP accelerator [http://us2.php.net/apc Alternative PHP Cache (APC)], using the following command.
<pre>
yum install lighttpd lighttpd-fastcgi mysql php php-mysql \
php-pecl-apc php-gd php-mbstring php-xmlrpc php-pdo ;
</pre>
Edit /etc/lighttpd/lighttpd.conf to point to the Moodle root directory and the ''PHP-CGI'' area to activate and point to PHP's fastcgi executable, under the respective sections:
<pre>
## a static document-root example
server.document-root = "/home/moodle-1.9/"
#### fastcgi module
fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => "/tmp/php-fastcgi.socket",
"bin-path" => "/usr/bin/php-cgi"
)
)
)
</pre>
Since Moodle maintains its own logs and reporting tools, you can disable lighttpd's server-level logging by commenting out (put a # mark in front of) the following lines in /etc/lighttpd/lighttpd.conf, as follows under the respective sections.
<pre>
## modules to load
# "mod_accesslog"
#### accesslog module
#accesslog.filename = "/var/log/lighttpd/access_log"
</pre>
If your server has CPU cycles to spare, enabling compression improves network speed and the student's perceived response time, especially for off-campus and distance learners. Compression should be separated at the HTTP and PHP levels to maximize CPU cycles (especially on multiple-CPU or multi-core systems). First uncomment the compression module in /etc/lighttpd/lighttpd.conf, create a directory for the compressed file temporary store (in this example, it's /home/compress.tmp) and enter it along with the types of files to compress (do not include PHP mimetypes here), as follows under the respective sections:
<pre>
## modules to load
# NOTE: a comma (,) is necessary when other active modules follow this one,
# unnecessary when this is the final active module in the server.modules directive
"mod_compress" #,
#### compress module
compress.cache-dir = "/home/compress.tmp/"
compress.filetype = ("text/plain", "text/javascript", "text/css", "text/xml")
</pre>
Second, edit /etc/php.ini to enable compression on the PHP output and consider increasing the maximum server submission size (individual courses can still be limited lower than and up to this limit within Moodle itself, if needed).
<pre>
zlib.output_compression = On
post_max_size = 32M
</pre>
==See Also==
* [http://tracker.moodle.org/browse/MDL-14638 Networking issue related to lighttpd]
* [http://en.wlmp-project.net/downloads.php WLMP project downloads for Windows packages]

lighttpd

2009-01-10T07:49:30Z

Fechevarria:

lighttpd

2009-01-10T07:43:41Z

Fechevarria:

[http://www.lighttpd.net/ Lighttpd] (a.k.a. Lighty) is a lightweight webserver with a small memory footprint. It is an alternative to Apache and IIS, particularly well suited to systems with low resources, especially RAM. Lighttpd is ideal for people using VPS hosting. Even on hosts with plenty of resources, Lighty is just as fast as Apache if not faster and well worth considering.

Installation varies according to platform, so if the following example doesn't apply to your server configuration, check the official instruction page [http://trac.lighttpd.net/trac/wiki/TutorialInstallation here]. You will also need to install php (preferrably with an accelerator) and fast-cgi according to [http://trac.lighttpd.net/trac/wiki/TutorialLighttpdAndPHP these] instructions.

lighttpd works well with PHP accelerators like [http://eaccelerator.net/ eAccelerator] and [http://us2.php.net/apc Alternative PHP Cache (APC)].

A notable difference between Lighttpd and Apache is the expires directive that controls the caching of content. Apache allows you to set the expiry by file type, e.g. making a jpg image stay in the browser cache for a week, older versions of Lighttpd specify folders to be cached. Versions with ETag generation support provide full expiry mechanisms and control.

===Fedora 6, 7, 8 & 9 Example===
On the latest versions of Fedora, lighttpd is a part of the official repository and can be installed using yum to meet all of Moodle's base requirements, including the PHP accelerator [http://us2.php.net/apc Alternative PHP Cache (APC)], using the following command.
<pre>
yum install lighttpd lighttpd-fastcgi mysql php php-mysql \
php-pecl-apc php-gd php-mbstring php-xmlrpc php-pdo ;
</pre>
Edit /etc/lighttpd/lighttpd.conf to point to the Moodle root directory and the ''PHP-CGI'' area to activate and point to PHP's fastcgi executable, under the respective sections:
<pre>
## a static document-root example
server.document-root = "/home/moodle-1.9/"
#### fastcgi module
fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => "/tmp/php-fastcgi.socket",
"bin-path" => "/usr/bin/php-cgi"
)
)
)
</pre>
Since Moodle maintains its own logs and reporting tools, you can disable lighttpd's server-level logging by commenting out (put a # mark in front of) the following lines in /etc/lighttpd/lighttpd.conf, as follows under the respective sections.
<pre>
## modules to load
# "mod_accesslog"
#### accesslog module
#accesslog.filename = "/var/log/lighttpd/access_log"
</pre>
If your server has CPU cycles to spare, enabling compression improves network speed and the student's perceived response time, especially for off-campus and distance learners. Compression should be separated at the HTTP and PHP levels to maximize CPU cycles (especially on multiple-CPU or multi-core systems). First uncomment the compression module in /etc/lighttpd/lighttpd.conf, create a directory for the compressed file temporary store (in this example, it's /home/compress.tmp) and enter it along with the types of files to compress (do not include PHP mimetypes here), as follows under the respective sections:
<pre>
## modules to load
# NOTE: a comma (,) is necessary when other active modules follow this one,
# unnecessary when this is the final active module in the server.modules directive
"mod_compress" #,
#### compress module
compress.cache-dir = "/home/compress.tmp/"
compress.filetype = ("text/plain", "text/javascript", "text/css", "text/xml")
</pre>
Second, edit /etc/php.ini to enable compression on the PHP output and consider increasing the maximum server submission size (individual courses can still be limited lower than and up to this limit within Moodle itself, if needed).
<pre>
zlib.output_compression = On
post_max_size = 32M
</pre>
==See Also==
* [http://tracker.moodle.org/browse/MDL-14638 Networking issue related to lighttpd]
* [http://en.wlmp-project.net/downloads.php WLMP project downloads for Windows packages]

lighttpd

2009-01-10T07:30:30Z

Fechevarria:

[http://www.lighttpd.net/ Lighttpd] (a.k.a. Lighty) is a lightweight webserver with a small memory footprint. It is an alternative to Apache and IIS, particularly well suited to systems with low resources, especially RAM. Lighttpd is ideal for people using VPS hosting. Even on hosts with plenty of resources, Lighty is just as fast as Apache if not faster and well worth considering.

Installation varies according to platform, so if the following example doesn't apply to your server configuration, check the official instruction page [http://trac.lighttpd.net/trac/wiki/TutorialInstallation here]. You will also need to install php (preferrably with an accelerator) and fast-cgi according to [http://trac.lighttpd.net/trac/wiki/TutorialLighttpdAndPHP these] instructions.

It has been found to work well with PHP accelerators like [http://eaccelerator.net/ eAccelerator] and [http://us2.php.net/apc Alternative PHP Cache (APC)].

One notable difference between Lighttpd and Apache is the expires directive that controls the caching of content. Apache allows you to set the expiry by file type e.g. making a jpg image stay in the browser cache for a week. Lighttpd will only let you specify folders to be cached.

===Fedora 6, 7, 8 & 9 Example===
On the latest versions of Fedora, lighttpd is a part of the official repository and can be installed using yum to meet all of Moodle's base requirements, including the PHP accelerator [http://us2.php.net/apc Alternative PHP Cache (APC)], using the following command.
<pre>
yum install lighttpd lighttpd-fastcgi mysql php php-mysql \
php-pecl-apc php-gd php-mbstring php-xmlrpc php-pdo ;
</pre>
Edit /etc/lighttpd/lighttpd.conf to point to the Moodle root directory and the ''PHP-CGI'' area to activate and point to PHP's fastcgi executable, under the respective sections:
<pre>
## a static document-root example
server.document-root = "/home/moodle-1.9/"
#### fastcgi module
fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => "/tmp/php-fastcgi.socket",
"bin-path" => "/usr/bin/php-cgi"
)
)
)
</pre>
Since Moodle maintains its own logs and reporting tools, you can disable lighttpd's server-level logging by commenting out (put a # mark in front of) the following lines in /etc/lighttpd/lighttpd.conf, as follows under the respective sections.
<pre>
## modules to load
# "mod_accesslog"
#### accesslog module
#accesslog.filename = "/var/log/lighttpd/access_log"
</pre>
If your server has CPU cycles to spare, enabling compression improves network speed and perceived response time, especially for distance learners. Compression should be separated at the HTTP and PHP levels to maximize CPU cycles (especially on multiple-CPU or multi-core systems). First uncomment the compression module in /etc/lighttpd/lighttpd.conf, create a directory for the compressed file temporary store (in this example, it's /home/compress.tmp) and enter it along with the types of files to compress (do not include PHP mimetypes here), as follows under the respective sections:
<pre>
## modules to load
# a comma may or may not be necessary depending on whether other active modules are listed after
"mod_compress"
#### compress module
compress.cache-dir = "/home/compress.tmp/"
compress.filetype = ("text/plain", "text/javascript", "text/css", "text/xml")
</pre>
Second, edit /etc/php.ini to enable compression on the PHP output and consider increasing the maximum server submission size (individual courses can still be limited lower than and up to this limit within Moodle itself, if needed).
<pre>
zlib.output_compression = On
post_max_size = 32M
</pre>
==See Also==
* [http://tracker.moodle.org/browse/MDL-14638 Networking issue related to lighttpd]
* [http://en.wlmp-project.net/downloads.php WLMP project downloads for Windows packages]

lighttpd

2009-01-09T20:01:07Z

Fechevarria:

[http://www.lighttpd.net/ Lighttpd] (a.k.a. Lighty) is a lightweight webserver with a small memory footprint. It is an alternative to Apache and IIS, particularly well suited to systems with low resources, especially RAM. Lighttpd is ideal for people using VPS hosting. Even on hosts with plenty of resources, Lighty is just as fast as Apache if not faster and well worth considering.

Installation varies according to platform, so if the following example doesn't apply to your server configuration, check the official instruction page [http://trac.lighttpd.net/trac/wiki/TutorialInstallation here]. You will also need to install php (preferrably with an accelerator) and fast-cgi according to [http://trac.lighttpd.net/trac/wiki/TutorialLighttpdAndPHP these] instructions.

It has been found to work well with PHP accelerators, for example [http://eaccelerator.net/ eAccelerator].

One notable difference between Lighttpd and Apache is the expires directive that controls the caching of content. Apache allows you to set the expiry by file type e.g. making a jpg image stay in the browser cache for a week. Lighttpd will only let you specify folders to be cached.

===Fedora 6, 7, 8 & 9 Example===

On the latest versions of Fedora, lighttpd is a part of the official repository and can be installed using yum to meet all of Moodle's base requirements, including a PHP accelerator [http://us2.php.net/apc APC] using the following command.
<pre>
yum install lighttpd lighttpd-fastcgi mysql php php-mysql \
php-pecl-apc php-gd php-mbstring php-xmlrpc php-pdo ;
</pre>
Edit /etc/lighttpd/lighttpd.conf to point to the Moodle root directory and the ''PHP-CGI'' area to activate and point to PHP's fastcgi executable, under the respective sections:
<pre>
## a static document-root example
server.document-root = "/home/moodle-1.9/"
#### fastcgi module
fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => "/tmp/php-fastcgi.socket",
"bin-path" => "/usr/bin/php-cgi"
)
)
)
</pre>

Since Moodle maintains its own logs and reporting tools, you can disable lighttpd's server-level logging by commenting out (put a # mark in front of) the following lines in /etc/lighttpd/lighttpd.conf, as follows under the respective sections.

<pre>
## modules to load
# "mod_accesslog"
#### accesslog module
#accesslog.filename = "/var/log/lighttpd/access_log"
</pre>

If your server has CPU cycles to spare, enabling compression improves perceived response time, especially for distance learners and should be separated at the HTTP and PHP levels to maximize CPU cycles (especially on multiple-CPU or multi-core systems). First uncomment the compression module in /etc/lighttpd/lighttpd.conf, create a directory for the compressed file temporary store (in this example, it's /home/compress.tmp) and enter it along with the types of files to compress (do not include PHP mimetypes here), as follows under the respective sections:

<pre>
## modules to load
"mod_compress"
# a comma may or may not be necessary depending on whether other modules are listed after
#### compress module
compress.cache-dir = "/home/compress.tmp/"
compress.filetype = ("text/plain", "text/javascript", "text/css", "text/xml")
</pre>

Second, edit /etc/php.ini to enable compression on the PHP output and increase the maximum server submission size (individual courses can still be limited below and up to this limit within Moodle itself).

<pre>
zlib.output_compression = On
post_max_size = 32M
</pre>

==See Also==

* [http://tracker.moodle.org/browse/MDL-14638 Networking issue related to lighttpd]
* [http://en.wlmp-project.net/downloads.php WLMP project downloads for Windows packages]

Performance recommendations

2009-01-09T16:35:53Z

Fechevarria:

Location: ''Administration > Server > Performance''

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. When trying to optimize your server, try to focus on the factor which will make the most difference to the user. For example, if you have relatively more users browsing than accessing the database, look to improve the webserver performance.

==Obtain a baseline benchmark==

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.

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

==Scalability==

Moodle's design (with clear separation of application layers) allows for strongly scalable setups. (Please check the list of [[Large installations|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.

'''See also''':
*[http://moodle.org/mod/forum/discuss.php?d=4801 Scalability] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=57202 Moodle clustering] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=44470 Software load balancing] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=49986 TCP load balancing] forum dicsussion.

==Hardware configuration==
'''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.
* 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 [http://en.wikipedia.org/wiki/Super_PI 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.
* Check the settings on your '''network card'''. You may get an improvement in performance by increasing the use of buffers and transmit/receive descriptors (balance this with processor and memory overheads) and off-loading TCP checksum calculation onto the card instead of the OS.
* Read this [http://moodle.org/mod/forum/discuss.php?d=68579 Case Study] on a server stress test with 300 users.
* See this [http://elearning.sgu.ac.jp/doc/PT/ accompanying report] on network traffic and server loads.

==Operating System==
* You can use [http://en.wikipedia.org/wiki/Linux Linux](recommended), Unix-based, Windows or Mac OS X 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. If you have a large number of processors running SMP, you may also want to consider using a highly tuned OS such as [http://en.wikipedia.org/wiki/Solaris_Operating_Environment Solaris].
* Check your own OS and '''vendor specific instructions''' for optimization steps.
** For Linux look at the [http://linuxperf.sourceforge.net/ 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 [http://technet.microsoft.com/ Microsoft TechNet site] for optimization documents.

==Web server performance==

Installing [http://www.mozilla.com/en-US/ Firefox] and the [https://addons.mozilla.org/en-US/firefox/addon/1843 firebug] extension will allow you to watch the time it takes for each page component to load. Also, the [https://addons.mozilla.org/en-US/firefox/addon/5369 Yslow] extension will evaluate your page against Yahoo's [http://www.skrenta.com/2007/05/14_rules_for_fast_web_pages_by_1.html 14 rules] ([http://video.yahoo.com/video/play?vid=1040890 video]) for fast loading websites.

===PHP performance===
* You are strongly recommended to use a '''PHP accelerator''' to ease CPU load, such as [http://pecl.php.net/apc APC], [http://www.php-accelerator.co.uk/ PHPA], [http://trac.lighttpd.net/xcache/ Xcache] or [http://eaccelerator.net/ 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 [http://turckmmcache.exeprod.com/TheManifestoEnglish no longer maintained] and can cause failures with PHP 5).
* Improvements in read/write performance can be improved by putting the cached PHP pages on a [[TMPFS]] filesystem - but remember that you'll lose the cache contents when there is a power failure or the server is rebooted.
* Performance of PHP is better when installed as an '''Apache/IIS ISAPI module''' (rather than a CGI).
* Also check the '''memory_limit''' in php.ini, reduce it to 16M for Moodle version earlier than 1.7 ([http://moodle.org/mod/forum/discuss.php?d=39656 See this forum discussion]). For Moodle 1.7 or later, it is recommended that the value of memory_limit should be 40M. As of [http://www.php.net/ChangeLog-5.php PHP 5.2.1] the default value for the memory_limit directive is 128M.

===Apache performance===
* If you are using Apache on a Windows server, use the build from [http://www.apachelounge.com Apache Lounge] which is reported to have [http://moodle.org/mod/forum/discuss.php?d=93358 performance and stability improvements] compared to the official Apache download. Note that this is an unofficial build, so may not keep up with official releases.
* Set the '''MaxClients''' directive correctly. Use this formula to help (which uses 80% of available memory to leave room for spare):
MaxClients = Total available memory * 80% / Max memory usage of apache process
:Memory usage of apache process is usually 10MB, so a general rule of thumb is to divide your available memory in megabytes by 10 to get the value of MaxClients. To find the max memory usage of apache processes read the value from the shell command:
#ps -ylC httpd --sort:rss

:If you need to increase the value of '''MaxClients''' beyond 256, you will also need to set the '''ServerLimit''' directive.

:'''Warning''': Do not be tempted to set the value of MaxClients higher than your available memory as your server will consume more RAM than available and start to swap to disk.
* Consider reducing the '''number of modules''' that Apache loads in the httpd.conf file to the minumum necessary to reduce the memory needed.
* Use the '''latest version of Apache''' - Apache 2 has an improved memory model 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 setting '''KeepAlive Off''' (do this only if your Moodle pages do not contain links to resources or uploaded images) or 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. A more accurate value for KeepAliveTimeout is obtained by observing how long it takes your users to download a page. After altering any of the KeepAlive variables, monitor your CPU utilization as there may be an additional overhead in initiating more worker processes/threads.
* As an alternative to using KeepAlive Off, consider setting-up a '''Reverse Proxy server''' infront of the Moodle server to cache HTML files with images. You can then return Apache to using keep-alives on the Moodle server.
* If you do not use a .htaccess file, set the '''AllowOverride''' variable to AllowOverride None to prevent .htaccess lookups.
* Set '''DirectoryIndex''' correctly so as to avoid content-negotiation. Here's an example from a production server:
DirectoryIndex index.php index.html index.htm
* Unless you are doing development work on the server, set '''ExtendedStatus Off''' and disable mod_info as well as mod_status.
* Leave '''HostnameLookups Off''' (as default) to reduce DNS latency.
* Consider reducing the value of '''TimeOut''' to between 30 to 60 (seconds).
* For the '''Options directive''', avoid Options Multiviews as this performs a directory scan. To reduce disk I/O further use
Options -Indexes FollowSymLinks
*'''Caching''' - Apache can be told to make pages load a lot faster by specifying that the browser should cache some various page elements such as images and reuse them from local memory rather than ask for them again every time a page is requested. How to do this varies slightly between OSes but there are two basic steps:

# Install and enable mod_expires - refer to documentation or man pages
# Add this code to the virtual server config file within the <directory> section for the root directory (or within the .htaccess file if AllowOverrides is On):
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType text/html "access plus 1 seconds"
ExpiresByType image/gif "access plus 1 week"
ExpiresByType image/jpeg "access plus 1 week"
ExpiresByType image/png "access plus 1 week"
ExpiresByType text/css "access plus 1 week"
ExpiresByType text/javascript "access plus 1 week"
ExpiresByType application/x-javascript "access plus 1 week"
ExpiresByType text/xml "access plus 1 seconds"
</IfModule>

The effect is to make everything stay in the cache except HTML and XML, which change dynamically. It's possible to gain a several hundred percent decrease in load times this way. Adjust the cache times according to how often your images etc change.

More info: [http://www.metaskills.net/blog/heuristics/sysadmin/how-to-control-browser-caching-with-apache-2 www.metaskills.net]

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

===Lighttpd performance===
You can increase web server performance by using the '''light-weight webserver''' [http://www.lighttpd.net/ lighttpd] in combination with PHP in fastCGI-mode. Lighttpd has a lower memory consumption than Apache - typically 10M for each process. See this [[lighttpd | MoodleDocs Lighttpd page]] for configuration and administration links.

==Database performance==

Moodle contains a script which will display some key database performance statistics from the [http://phplens.com/lens/adodb/docs-perf.htm ADOdb performance monitor]. Run the script in your browser as in the following example:

http://www.mymoodle.com/admin/dbperformance.php

Use the data displayed as a guide to tune and improve the performance of your database server.

===MySQL performance===

The following are MySQL specific settings which can be adjusted for better performance in your my.cnf (my.ini in Windows). The file contains a list of settings and their values. To see the current values use these commands
SHOW STATUS;
SHOW VARIABLES;
'''Important''': You must make backups of your database before attempting to change any MySQL server configuration. After any change to the my.cnf, restart mysqld.

If you are able, the [http://wiki.mysqltuner.com/MySQLTuner MySQLTuner] tool can be run against your MySQL server and will calculate appropriate configuration values for most of the following settings based on your current load, status and variables automatically.

* Enable the '''query cache''' with
query_cache_type = 1.
For most Moodle installs, set the following:
query_cache_size = 36M
query_cache_min_res_unit = 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
table_cache = 256
(min), and for Moodle 1.7 set
table_cache = 512
(min). The table cache is used by all threads (connections), so monitor the value of opened_tables to further adjust - if opened_tables > 3 * table_cache then increase table_cache upto your OS limit. Note also that the figure for table_cache will also 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 returned and set table_cache to this value.
mysql>SELECT COUNT(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 for 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.
* '''Optimize your tables weekly and after upgrading 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 [http://dev.mysql.com/doc/refman/5.0/en/repair-table.html MySQL manual] and this [http://moodle.org/mod/forum/discuss.php?d=58208#p279638 forum script]).
* '''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
:'''Warning''': You must stop the mysql database process (mysqld) before running any myisamchk command. If you do not, you risk data loss.
* Reduce the number of '''temporary tables saved to disk'''. Check this with the created_tmp_disk_tables value. If this is relatively large (>5%) increase tmp_table_size until you see a reduction. Note that this will have an impact on RAM usage.
* Moodle's tables are in the MyISAM format, so '''turn InnoDB off''' as there is no performance gain. Add <code>skip-innodb</code> to your <code>my.cnf</code> file. If you must use InnoDB, you'll have to convert all of Moodle's tables. To do this run the innodb script:

http://www.mymoodle.com/admin/innodb.php

:See also [http://moodle.org/mod/forum/discuss.php?d=12961 this forum discussion] which looks at the MyISAM vs InnoDB options.

===PostgreSQL performance===

There are some good papers around on tuning PostgreSQL, and Moodle's case does not seem to be different to the general case.

The first thing to recognise is that if you really need to worry about tuning you should be using a separate machine for the database server. If you are not using a separate machine then the answers to many performance questions are substantially muddied by the memory requirements of the rest of the application.

You should probably '''enable autovacuum''', unless you know what you are doing. Many e-learning sites have predictable periods of low use, so disabling autovacuum and running a specific vacuum at those times can be a good option. Or perhaps leave autovacuum running but do a full vacuum weekly in a quiet period.

Set '''shared_buffers''' to something reasonable. For versions up to 8.1 my testing has shown that peak performance is almost always obtained with buffers < 10000, so if you are using such a version, and have more than 512M of RAM just set shared_buffers to 10,000 (8MB).

The buffer management had a big overhaul in 8.2 and "reasonable" is now a much larger number. I have not conducted performance tests with 8.2, but the recommendations from others are generally that you should now scale shared_buffers much more with memory and may continue to reap benefits even up to values like 100,000 (80MB). Consider using 1-2% of system RAM.

PostgreSQL will also assume that the operating system is caching its files, so setting '''effective_cache_size''' to a reasonable value is also a good idea. A reasonable value will usually be (total RAM - RAM in use by programs). If you are running Linux and leave the system running for a day or two you can look at 'free' and under the 'cached' column you will see what it currently is. Consider taking that number (which is kB) and dividing it by 10 (i.e. allow 20% for other programs cache needs and then divide by 8 to get pages). If you are not using a dedicated database server you will need to decrease that value to account for usage by other programs.

Some other useful parameters that can have positive effects, and the values I would typically set them to on a machine with 4G RAM, are:

work_mem = 10240

That's 10M of RAM to use instead of on-disk sorting and so forth. That can give a big speed increase, but it is per connection and 200 connections * 10M is 2G, so it can theoretically chew up a lot of RAM.

maintenance_work_mem = 163840

That's 160M of RAM which will be used by (e.g.) VACUUM, index rebuild, cluster and so forth. This should only be used periodically and should be freed when those processes exit, so I believe it is well worth while.

max_fsm_pages = 100000
max_fsm_relations = 5000

These are used to hold the free-space map, and if they are too small you will see performance degradation after the database has been operating for some time. The exact numbers to set can be gleaned from the output of VACUUM VERBOSE, which prints the required FSM pages at the end of it's run. The 5x increase seems to be useful for a Moodle installation, from experience.

wal_buffers = 64

These buffers are used for the write-ahead log, and there have been a number of reports on the PostgreSQL mailing lists of improvement from this level of increase.

This is a little out of date now (version 8.0) but still worth a read: http://www.powerpostgresql.com/Docs

And there is lots of good stuff here as well: http://www.varlena.com/varlena/GeneralBits/Tidbits/index.php

''Based on Andrew McMillan's post at [http://moodle.org/mod/forum/discuss.php?d=68558 Tuning PostgreSQL] forum thread.''

===Other database performance links===
* Consider using a '''distributed cacheing system''' like [http://en.wikipedia.org/wiki/Memcached memcached] but note that memcached does not have any security features so it should be used behind a firewall.
* Consider using PostgreSQL. See [[Arguments in favour of PostgreSQL]] and [http://moodle.org/mod/forum/discuss.php?d=49195 how to migrate from MySQL to PostgreSQL] (forum discussion).
* [[Increasing the database connection lifetime | Try increasing the database connection lifetime]]
* [http://dev.mysql.com/doc/refman/5.0/en/server-parameters.html General advice on tuning MySQL parameters] (advice from the MySQL manual)
* [http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/ InnoDB performance optimization] taken from the [http://www.mysqlperformanceblog.com/ MySQL performance blog] site.

==Moodle Admin settings==
* In Moodle 1.7 or later, set the '''Cache type''' for your server: Site Admin -> Server -> Performance -> Cache type. There are several options available.
:*If you do not have eaccelerator or mmemcached installed, choose "internal" (which makes use of the record/internal cache - see the next bullet point).
:* If you have a single server and have compiled '''eaccelerator with shared memory support''', set the cache type to the eaccelerator option.
:* If you have a '''separate memcached server''', set the cache type to memcached and enter a csv list of server IP addresses.
* Enable the '''record/internal cache''': Site Admin -> Server -> Performance -> Record cache = True. Set the maximum amount of memory allocated to the cache in the Int Cache Max box. This will enable a primary cache for database records, without using any database engine cache, e.g. MySQL/PostgreSQL cache. See [http://tracker.moodle.org/browse/MDL-7196 this Tracker entry] for a full discussion.
* 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/Server/Cleanup).
* Performance can be greatly improved by allowing Moodle to use the system '''zip/unzip''' commands (rather than PHP-based zip libraries) - visit Admin/Server/System Paths 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).
* If there are performance problems loading course pages, check the '''Resource module settings'''. The setting resource_filterexternalpages is known to slow-down course pages and should be set to 'No' for better performance.
* Check your '''forum settings'''. To improve performance set forum_trackreadposts = No and forum_usermarksread = Yes (this will impact on the convenience of your users' forum experience). Also consider setting the time of the day when old posts are cleared from the read table (forum_cleanreadtime) to when your site is less busy.

==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 [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. When using the Chat module use the configuration settings to tune for your expected load. Pay particular attention to the ''chat_old_ping'' and ''chat_refresh'' parameters as these can have greatest impact on server load.
* The '''Quiz''' module is known to stretch database performance. Try to optimise your database server by tuning. See [http://moodle.org/mod/forum/discuss.php?d=25616&parent=120770 for a brief report on performance for 55 students simultaneously using quizzes]
** See this Case Study for an extensive server stress test with 300 quiz users.[http://moodle.org/mod/forum/discuss.php?d=68579] And this accompanying report on network traffic and server loads. [http://elearning.sgu.ac.jp/doc/PT/]
* 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 '''Recent activities''' block is consuming to much resources if you hvae huge number of records <code>mdl_log</code>. this is being tested to optimize the SQL query.

==See also==

*[[Performance FAQ]]
*Using Moodle [http://moodle.org/mod/forum/view.php?f=94 Hardware and Performance forum]

There have been a lot of discussions on moodle.org about performance, here are some of the more interesting and (potentially) useful ones:

* [http://moodle.org/mod/forum/discuss.php?d=83057 Performance woes!]
* [http://moodle.org/mod/forum/discuss.php?d=57028 Performance perspectives - a little script]
* [http://moodle.org/mod/forum/discuss.php?d=88927 Comments on planned server hardware]
* [http://moodle.org/mod/forum/discuss.php?d=102978#p461624 Moodle performance in a pil by Martin Langhoff]
[[Category:Performance]]

[[fr:Performance]]
[[ja:パフォーマンス]]
[[pl:Wydajność]]

Cron

2009-01-09T02:54:32Z

Fechevarria: /* Using a cron command line in Unix */

Cron assists some of Moodle's modules to perform tasks on a scheduled basis. For example, the cron process might tell Moodle to check all discussion forums so it can mail out copies of new posts to people who have subscribed to that forum.

The primary Moodle script that does all this is located in the admin directory, and is called cron.php. However, it can not tell itself to run, so you need to set up a mechanism where this script is run regularly (eg every five or ten minutes). This provides a "heartbeat" so that the script can perform functions at periods defined by each module. This kind of regular mechanism is known as a '''cron service'''. The service can be part of a webhost or can be something run from a different server or computer.

==Overview of cron==
===Script overview===

The cron.php script looks through the mdl_modules table (assuming the default table prefix is mdl_) in the Moodle database for modules scheduled to have their cron functions run; it then looks in each such module directory for a function called module-name_cron in the lib.php file and runs it. It also looks through the mdl_block table for blocks scheduled for their cron methods (object functions) to be run; it then, for each such block, runs the cron method for a new object associated with that block (I'm omitting details for the benefit of non-programmers; programmers can read admin/cron.php for themselves). These files (the lib.php files and the files where the block classes are defined) can contain cleanup functions, email functions or anything that needs to be run on a regular basis. For example, cron will trigger the system to create the backups of courses at the time specified in the administration settings. It also triggers any messaging module or forum email notifications, but not all functions are called each time the cron runs. Some functions, such as unenrolling students who have not logged in or deleting old copies of log files, are only run occasionally. The cron.php file has a section which will randomly call these core tasks approximately 1 in 5 times the cron runs.

===Invocation===
There are now (1.9) a number of options with respect to how one can invoke cron.php. First off, one can password the invocation of cron.php via its URL. This means whether one calls the script via a browser through an application like wget or curl, or via your own code to the web daemon, the script will not run unless the password is provided, and this would be transmitted in clear text.

You can also now bar invocation by URL be selecting cronclionly. This sets Moodle so that cron.php cannot be invoked by the Moodle URL. See the illustration below.

[[Image:Moodelcronadmin.png]]

While this is identified as CLI (command line interface) this is a bit misleading in that it does not mean that you have to be sitting at a shell account entering the command. If you enable this switch you can invoke cron.php through any set of batch or script files you wish, but it must be invoked via its correct location in the operating systems file structure. This can be especially frustrating for those not used to scripting in that environment is not typically provided.

===Cron service location and timing===
Note that the machine performing the cron '''does not need to be the same machine that is running Moodle'''. For example, if you have a limited web hosting service that does not have a cron service, then you might choose to run cron on another server or on your home computer. All that matters is that the cron.php file is called regularly.

The load of this script is not very high, so 5 minutes is usually reasonable, but if you're worried about it you can reduce the time period to something like 15 minutes or even 30 minutes. It's best not to make the time period too long, as delaying mail-outs can slow down activity within the course. Remember that mail-outs also wait for the editing time to expire before being queued for sending.

===Testing cron and manual trigger===

First, test that the script works by running it directly from your browser: ''<nowiki>http://example.com/moodle/admin/cron.php</nowiki>''

If cron is called from the command line by any user logged in to your Moodle it will create a temporary admin environment in order to run and then log the user out. You can disable command line running of cron by disabling the appropriate section in the cron.php file.

Now, you need to set up some of way of running the script automatically and regularly.

==Managing Cron on Windows systems==

There are two different ways for setting-up Moodle cron.php on Windows systems:

*Use the '''Moodle Cron package'''. The simplest way is to use this little package [http://download.moodle.org/download.php/sourceforge/MoodleCron-Setup.exe MoodleCron-Setup.exe], which makes this whole thing very easy by installing a small Windows service. Run it and forget about it! :-)
*Use a '''Scheduled Task'''. If you prefer to use the built-in Windows Scheduler or are having trouble with moodle-cron-for-windows package, you can use wget for windows or php from the command line and setup a scheduled task. Just follow these steps:
** Choose either the '''php.exe/php-win.exe (command line binary)''' or '''wget'''
::The php.exe or php-win.exe binary (for PHP version 5 or later) is installed in your php folder (e.g. c:\php) will give you better performance when running the cron script.
::If you want to use wget, download a compiled version of wget for windows from the native GNU Win32 ports (http://unxutils.sourceforge.net/), from Heiko Herold's wget for windows page (http://xoomer.virgilio.it/hherold/) or Bart Puype's wget for windows page (http://users.ugent.be/~bpuype/wget/). If you use Heiko Herold's package, copy all of the .DLL files to your C:\Windows\system32 directory. Copy the wget.exe file to c:\windows (this makes sure wget is always in the search path).
:* Setup a '''Scheduled Task'''.
:: - Go to Start >> Control Panel >> Scheduled Tasks >> Add Scheduled Task.
:: - Click "Next" to start the wizard:
:: - Click in the "Browse..." button and browse to c:\php\php.exe or c:\windows\wget.exe and click "Open"
:: - Type "Moodle Cron" as the name of the task and select "Daily" as the schedule. Click "Next".
:: - Select "12:00 AM" as the start time, perform the task "Every Day" and choose today's date as the starting date. Click "Next".
:: - Enter the username and password of the user the task will run under (it doesn't have to be a priviledged account at all). Make sure you type the password correctly. Click "Next".
:: - Mark the checkbox titled "Open advanced properties for this task when I click Finish" and click "Finish".
:: - In the new dialog box, type the following in the "Run:" text box: <pre>c:\windows\wget.exe -q -O NUL http://my.moodle.site/moodle/admin/cron.php</pre> or <pre>c:\php\php-win.exe -f c:\moodle\admin\cron.php</pre> Replace "c:\moodle" with the path to your moodle directory or "my.moode.site" with the name of your site.<br><br>
:: - Click on the "Schedule" tab and there in the "Advanced..." button.
:: - Mark the "Repeat task" checkbox and set "Every:" to 5 minutes, and set "Until:" to "Duration" and type "23" hours and "59" minutes.
:: - Click "OK" and you are done.
* '''Test your scheduled task'''. You can test that your scheduled task can run successfully by clicking it with the right button and chosing "Run". If everything is correctly setup, you will briefly see a DOS command window while wget/php executes and fetches the cron page and then it disappears. If you refresh the scheduled tasks folder, you will see the ''Last Run Time column'' (in detailed folder view) reflects the current time, and that the Last Result column displays "0x0" (everything went OK). If either of these is different, then you should recheck your setup.
* '''Logging cron output'''. You may want to log the output of the cron script as it executes, in case you see the job is producing errors, backups are not being completed or users are experiencing delays in receiving forum emails. To do this, adjust the command so that it uses the php.exe and stores the output in a file called (for example c:\moodle\admin\cron.log). Here is an example of the php.exe command:
<pre>c:\php\php.exe -f c:\moodle\admin\cron.php > c:\moodle\admin\cron.log</pre>

==Managing cron on web hosting services==

Your web-based control panel may have a web page that allows you to set up a cron service process.

===CPanel cron service===
If you are using CPanel, login then look for "Advanced" category towards the bottom of the page. Click on Cron Jobs -> Advanced (Unix style). Enter the following for the cron to run every 30 minutes.

Email address for output: emailaddress@mydomain.con
Minute:*/30
Hour:*
Day:*
Month:*
Weekday:*
<nowiki>Command: wget -q -O /dev/null http://www.mydomain.com/moodle/admin/cron.php</nowiki>

Click Commit Changes. Check your email for the output.

[[Image:Cpanel-cron-setup.JPG]]

===Other systems cron service===
For other systems, look for a button called "Cron jobs". In there you can put the same sort of Unix commands as listed below.

If you don't have permissions to run the 'wget' command on the server, you can use this php command:

/usr/local/bin/php -q /real/path/to/script/admin/cron.php

For example:

/usr/local/bin/php -q /home/username/public_html/moodle/admin/cron.php

If you don't know what is the real path of your Moodle folder you can use the PHP command realpath.

Another alternative, if you do not have permission to run the 'wget' command, may be to use a curl command.

For example:

curl --silent --compressed http://mydomain.com/moodle/admin/cron.php

==Using a cron command line in Unix==

There are different command line programs you can use to call the page from the command line. Not all of them may be available on a given server.

For example, you can use a Unix utility like 'wget':

wget -q -O /dev/null <nowiki>http://example.com/moodle/admin/cron.php</nowiki>

Note in this example that the output is thrown away (to /dev/null).

A number of users of Moodle have found that 'wget' sometimes fails. Especially if you have trouble with email digests not being sent on a daily basis to all users, an alternative command that solves the problem is:

php <nowiki>http://example.com/moodle/admin/cron.php</nowiki>

The same thing using lynx:

lynx -dump <nowiki>http://example.com/moodle/admin/cron.php</nowiki> > /dev/null

Note in this example that the output is thrown away (to /dev/null).

Alternatively, you can use a standalone version of PHP, compiled to be run on the command line. The disadvantage is that you need to have access to a command-line version of php. The advantage is that your web server logs aren't filled with constant requests to cron.php and you can run at a lower I/O and CPU priority.

/opt/bin/php /web/moodle/admin/cron.php

Example command to run at lower priority:

ionice -c3 -p$$;nice -n 10 /usr/bin/php /moodle/admin/cron.php > /dev/null

===Using the crontab program on Unix===

All that Cpanel does is provide a web interface to a Unix utility known as crontab. If you have a command line, you can set up crontab yourself using the command:

crontab -e

and then adding one of the above commands like:

*/30 * * * * wget -q -O /dev/null <nowiki>http://example.com/moodle/admin/cron.php</nowiki>

The first five entries are the times to run values, followed by the command to run. The asterisk is a wildcard, indicating any time. The above example means run the command ''wget -q -O /dev/null...'' every 30 minutes (*/30), every hour (*), every day of the month (*), every month (*), every day of the week (*).

The "O" of "-O" is the capital letter not zero, and refers the output file destination, in this case "/dev/null" which is a black hole and discards the output. If you want to see the output of your cron.php then enter its url in your browser.

* [http://linuxweblog.com/node/24 A basic crontab tutorial]
* [http://www.freebsd.org/cgi/man.cgi?query=crontab&apropos=0&sektion=5&manpath=FreeBSD+6.0-RELEASE+and+Ports&format=html Online version of the man page]

For '''beginners''', "EDITOR=nano crontab -e" will allow you to edit the crontab using the [http://www.nano-editor.org/dist/v1.2/faq.html nano] editor. Ubuntu defaults to using the nano editor.

Usually, the "crontab -e" command will put you into the 'vi' editor. You enter "insert mode" by pressing "i", then type in the line as above, then exit insert mode by pressing ESC. You save and exit by typing ":wq", or quit without saving using ":q!" (without the quotes). Here is an [http://www.unix-manuals.com/tutorials/vi/vi-in-10-1.html intro] to the 'vi' editor.

==See also==

Using Moodle forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=41827 Cron - can someone give me a quick confirmation of function?]
*[http://moodle.org/mod/forum/discuss.php?d=97684 Cronjob Question]
*[http://moodle.org/mod/forum/discuss.php?d=97457 Slow cron : avoiding simultaneous cron]

[[Category:Installation]]

[[es:Cron]]
[[fr:Cron]]
[[nl:Cron]]
[[sk:Cron]]
[[pl:Cron]]
[[ja:Cron]]