MoodleDocs - Användarbidrag [sv]

Session handling

2022-08-03T07:24:37Z

Brendanheywood: /* Read only sessions */

{{Server settings}}
An administrator can change the following settings in 'Session Handling' in the Site administration.

Once someone logs in to your Moodle server, the server starts a session. The session data allows the server to track users as they access different pages.
==Use database for session information==
Moodle needs to store the session data in some storage. By default either file or database session storage is selected, this option allows admin to change it. Large installation should use memcached driver described below.

Note that this option disappears after setting the $CFG->session_handler_class in config.php file.
==Timeout==
If users don't load a new page during the amount of time set here, Moodle will end their session and log them out.

Be sure this time frame is long enough to cover the longest test your teachers may offer. If a student is logged out while they are taking a test, their responses to the test questions may be lost.
==Cookie prefix==
Most of the time, you can leave this blank, unless you are running more than one Moodle site on the same server. In this case, you will want to customize the name of the cookie each Moodle site uses to track the session. This enables you to be logged into more than one Moodle site at the same time.

Note: If you change "Cookie prefix" or "Cookie path" you will need to login again as the changes take effect immediately.
==Cookie path==
The relative path to this Moodle installation, this may be used to force sending of Moodle session cookie to parent directories. Invalid values are ignored automatically.
==Cookie domain==
This can be used to send session cookies to higher domains instead of just the server domain. This may be useful for some SSO solutions. Invalid values are ignored automatically.
==Session drivers==
User sessions may be stored in different backends. Session drivers can be configured only in config.php file - see examples in config-dist.php file.
===Memcached session driver===
The Memcached session driver is the fastest driver. It requires external memcached server and memcached PHP extension. Server cluster nodes must use shared session storage.

Configuration options in config.php:
<syntaxhighlight lang="php">
$CFG->session_handler_class = '\core\session\memcached';
$CFG->session_memcached_save_path = '127.0.0.1:11211';
$CFG->session_memcached_prefix = 'memc.sess.key.';
$CFG->session_memcached_acquire_lock_timeout = 120;
$CFG->session_memcached_lock_expire = 7200; // Ignored if memcached extension <= 2.1.0
</syntaxhighlight>
Notes:
* Make sure the memcached server has enough memory.
* Use different prefix when storing sessions from multiple Moodle sites in one server.
* If PECL memcached extension version installed is less that 2.2.0, the locking works differently from other drivers - the lock is expired/released at the end of timeout - see MDL-42485.
* '''Don't use the same memcached server for both sessions and MUC. Events triggering MUC caches to be purged leads to MUC purging the memcached server - thus terminating ALL sessions.'''
* The <code php>$CFG->session_memcached_number_of_replicas</code> option is no longer supported.
For windows users, PHP.net only supplies binaries for memcache, (and not memcached). (http://windows.php.net/downloads/pecl/releases/)

(As of 2.7, two different contribs exist for memcache session handling - see MDL-42011 - it seems the OU one doesn't use prefix/lock_expire for some reason... possibly better to use the catalyst patch, where the only difference to the above config.php is the spelling of memcache(d).)
===File session driver===
This driver is used by default in new installation.

Configuration options in config.php:
<syntaxhighlight lang="php">
$CFG->session_handler_class = '\core\session\file';
$CFG->session_file_save_path = $CFG->dataroot.'/sessions';
</syntaxhighlight>
Notes:
* File based sessions require file system that supports file locking.
===Database session driver===
This type of driver was used by default in Moodle 2.0-2.5.
<syntaxhighlight lang="php">
$CFG->session_handler_class = '\core\session\database';
$CFG->session_database_acquire_lock_timeout = 120;
</syntaxhighlight>
Notes:
* DB sessions are not compatible with MyISAM database engine.
* If you are using MySQL/MariaDB make sure that \'max_allowed_packet\' in my.cnf (or my.ini) is at least 4M.
* The performance is relatively low, it is not recommended for large sites.
===Redis session driver===
The [[Redis]] session driver is available in Moodle 3.1.3 onwards (see MDL-54606). It requires a [[Redis_cache_store#Installing_Redis_server|Redis server]] and the [[Redis_cache_store#Installing_Redis_php_driver|Redis extension]].

Configuration options in config.php:
<syntaxhighlight lang="php">
$CFG->session_handler_class = '\core\session\redis';
$CFG->session_redis_host = '127.0.0.1';
$CFG->session_redis_port = 6379; // Optional.
$CFG->session_redis_database = 0; // Optional, default is db 0.
$CFG->session_redis_auth = ''; // Optional, default is don't set one.
$CFG->session_redis_prefix = ''; // Optional, default is don't set one.
$CFG->session_redis_acquire_lock_timeout = 120;
$CFG->session_redis_acquire_lock_retry = 100; // Optional, default is 100ms (from 3.9)
$CFG->session_redis_lock_expire = 7200;
$CFG->session_redis_serializer_use_igbinary = false; // Optional, default is PHP builtin serializer.
</syntaxhighlight>
Notes:
* Be careful on changing the default serializer: it requires <code php>--enable-redis-igbinary</code> at ''phpredis'' extension compile time '''and''' you need to remove '''the previous session data''' before using Moodle again.
== Read only sessions ==
There was an experimental feature introduced in Moodle 3.9 and is now stable since 3.11. It allows certain pages to start readonly sessions which do not require a write lock with the aim of high performance at scale.

https://tracker.moodle.org/browse/MDL-58018
=== Configuration ===
==== 1) Using a compliant session store ====
In order to use readonly sessions you need to be using a session store which supports it, which includes database and redis.
==== 2) Mapping session caches ====
By default all MUC 'session caches' are stored in the $SESSION which is a subtle distinction that is easily misunderstood. MUC caches can be read and written at any time and are independent of the $SESSION being locked. So all cache definitions which have a mode of session need to be mapped to a store which is not in the session such as in redis. If this isn't done errors will be raised highlighting the configuration issue.
==== 3) Turning it on in config.php ====
$CFG->enable_read_only_sessions = true;
If you have concerns about rolling this out, there is a soft rollout mode which report on any issues and you could leave this on for say a month or two and then turn it on fully:
$CFG->enable_read_only_sessions_debug = true;
==== 4) Adding support for it to core and plugins ====
Various critical pages and web services in core have been declared and implemented as readonly, if you want to support readonly sessions please read:
https://docs.moodle.org/dev/Session_locks
==See also==
* [[Sessions FAQ]]
[[cs:admin/setting/sessionhandling]]
[[ja:セッションハンドリング]]
[[de:Sitzungsinformationen]]
[[es:Manejo de la sesión]]
[[fr:Gestion des sessions]]

Session handling

2022-08-03T07:23:41Z

Brendanheywood: /* Read only sessions */

{{Server settings}}
An administrator can change the following settings in 'Session Handling' in the Site administration.

Once someone logs in to your Moodle server, the server starts a session. The session data allows the server to track users as they access different pages.

==Use database for session information==

Moodle needs to store the session data in some storage. By default either file or database session storage is selected, this option allows admin to change it. Large installation should use memcached driver described below.

Note that this option disappears after setting the $CFG->session_handler_class in config.php file.

==Timeout==

If users don't load a new page during the amount of time set here, Moodle will end their session and log them out.

Be sure this time frame is long enough to cover the longest test your teachers may offer. If a student is logged out while they are taking a test, their responses to the test questions may be lost.

==Cookie prefix==

Most of the time, you can leave this blank, unless you are running more than one Moodle site on the same server. In this case, you will want to customize the name of the cookie each Moodle site uses to track the session. This enables you to be logged into more than one Moodle site at the same time.

Note: If you change "Cookie prefix" or "Cookie path" you will need to login again as the changes take effect immediately.

==Cookie path==

The relative path to this Moodle installation, this may be used to force sending of Moodle session cookie to parent directories. Invalid values are ignored automatically.

==Cookie domain==

This can be used to send session cookies to higher domains instead of just the server domain. This may be useful for some SSO solutions. Invalid values are ignored automatically.

==Session drivers==
User sessions may be stored in different backends. Session drivers can be configured only in config.php file - see examples in config-dist.php file.

===Memcached session driver===
The Memcached session driver is the fastest driver. It requires external memcached server and memcached PHP extension. Server cluster nodes must use shared session storage.

Configuration options in config.php:
<syntaxhighlight lang="php">
$CFG->session_handler_class = '\core\session\memcached';
$CFG->session_memcached_save_path = '127.0.0.1:11211';
$CFG->session_memcached_prefix = 'memc.sess.key.';
$CFG->session_memcached_acquire_lock_timeout = 120;
$CFG->session_memcached_lock_expire = 7200; // Ignored if memcached extension <= 2.1.0
</syntaxhighlight>

Notes:
* Make sure the memcached server has enough memory.
* Use different prefix when storing sessions from multiple Moodle sites in one server.
* If PECL memcached extension version installed is less that 2.2.0, the locking works differently from other drivers - the lock is expired/released at the end of timeout - see MDL-42485.
* '''Don't use the same memcached server for both sessions and MUC. Events triggering MUC caches to be purged leads to MUC purging the memcached server - thus terminating ALL sessions.'''
* The <code php>$CFG->session_memcached_number_of_replicas</code> option is no longer supported.

For windows users, PHP.net only supplies binaries for memcache, (and not memcached). (http://windows.php.net/downloads/pecl/releases/)

(As of 2.7, two different contribs exist for memcache session handling - see MDL-42011 - it seems the OU one doesn't use prefix/lock_expire for some reason... possibly better to use the catalyst patch, where the only difference to the above config.php is the spelling of memcache(d).)

===File session driver===
This driver is used by default in new installation.

Configuration options in config.php:
<syntaxhighlight lang="php">
$CFG->session_handler_class = '\core\session\file';
$CFG->session_file_save_path = $CFG->dataroot.'/sessions';
</syntaxhighlight>

Notes:
* File based sessions require file system that supports file locking.

===Database session driver===
This type of driver was used by default in Moodle 2.0-2.5.

<syntaxhighlight lang="php">
$CFG->session_handler_class = '\core\session\database';
$CFG->session_database_acquire_lock_timeout = 120;
</syntaxhighlight>

Notes:
* DB sessions are not compatible with MyISAM database engine.
* If you are using MySQL/MariaDB make sure that \'max_allowed_packet\' in my.cnf (or my.ini) is at least 4M.
* The performance is relatively low, it is not recommended for large sites.

===Redis session driver===

The [[Redis]] session driver is available in Moodle 3.1.3 onwards (see MDL-54606). It requires a [[Redis_cache_store#Installing_Redis_server|Redis server]] and the [[Redis_cache_store#Installing_Redis_php_driver|Redis extension]].

Configuration options in config.php:
<syntaxhighlight lang="php">
$CFG->session_handler_class = '\core\session\redis';
$CFG->session_redis_host = '127.0.0.1';
$CFG->session_redis_port = 6379; // Optional.
$CFG->session_redis_database = 0; // Optional, default is db 0.
$CFG->session_redis_auth = ''; // Optional, default is don't set one.
$CFG->session_redis_prefix = ''; // Optional, default is don't set one.
$CFG->session_redis_acquire_lock_timeout = 120;
$CFG->session_redis_acquire_lock_retry = 100; // Optional, default is 100ms (from 3.9)
$CFG->session_redis_lock_expire = 7200;
$CFG->session_redis_serializer_use_igbinary = false; // Optional, default is PHP builtin serializer.
</syntaxhighlight>

Notes:
* Be careful on changing the default serializer: it requires <code php>--enable-redis-igbinary</code> at ''phpredis'' extension compile time '''and''' you need to remove '''the previous session data''' before using Moodle again.

== Read only sessions ==
There is an experimental feature introduced in Moodle 3.9 and stable in 3.11. It allows certain pages to start readonly sessions which do not require a write lock with the aim of high performance at scale.

https://tracker.moodle.org/browse/MDL-58018
=== Configuration ===
==== 1) Using a compliant session store ====
In order to use readonly sessions you need to be using a session store which supports it, which includes database and redis.
==== 2) Mapping session caches ====
By default all MUC 'session caches' are stored in the $SESSION which is a subtle distinction that is easily misunderstood. MUC caches can be read and written at any time and are independent of the $SESSION being locked. So all cache definitions which have a mode of session need to be mapped to a store which is not in the session such as in redis. If this isn't done errors will be raised highlighting the configuration issue.
==== 3) Turning it on in config.php ====
$CFG->enable_read_only_sessions = true;
If you have concerns about rolling this out, there is a soft rollout mode which report on any issues and you could leave this on for say a month or two and then turn it on fully:
$CFG->enable_read_only_sessions_debug = true;

==== 4) Adding support for it to core and plugins ====
Various critical pages and web services in core have been declared and implemented as readonly, if you want to support readonly sessions please read:
https://docs.moodle.org/dev/Session_locks

==See also==
* [[Sessions FAQ]]

[[cs:admin/setting/sessionhandling]]
[[ja:セッションハンドリング]]
[[de:Sitzungsinformationen]]
[[es:Manejo de la sesión]]
[[fr:Gestion des sessions]]

Session handling

2022-08-03T07:23:21Z

Brendanheywood: /* Read only sessions */

{{Server settings}}
An administrator can change the following settings in 'Session Handling' in the Site administration.

Once someone logs in to your Moodle server, the server starts a session. The session data allows the server to track users as they access different pages.

==Use database for session information==

Moodle needs to store the session data in some storage. By default either file or database session storage is selected, this option allows admin to change it. Large installation should use memcached driver described below.

Note that this option disappears after setting the $CFG->session_handler_class in config.php file.

==Timeout==

If users don't load a new page during the amount of time set here, Moodle will end their session and log them out.

Be sure this time frame is long enough to cover the longest test your teachers may offer. If a student is logged out while they are taking a test, their responses to the test questions may be lost.

==Cookie prefix==

Most of the time, you can leave this blank, unless you are running more than one Moodle site on the same server. In this case, you will want to customize the name of the cookie each Moodle site uses to track the session. This enables you to be logged into more than one Moodle site at the same time.

Note: If you change "Cookie prefix" or "Cookie path" you will need to login again as the changes take effect immediately.

==Cookie path==

The relative path to this Moodle installation, this may be used to force sending of Moodle session cookie to parent directories. Invalid values are ignored automatically.

==Cookie domain==

This can be used to send session cookies to higher domains instead of just the server domain. This may be useful for some SSO solutions. Invalid values are ignored automatically.

==Session drivers==
User sessions may be stored in different backends. Session drivers can be configured only in config.php file - see examples in config-dist.php file.

===Memcached session driver===
The Memcached session driver is the fastest driver. It requires external memcached server and memcached PHP extension. Server cluster nodes must use shared session storage.

Configuration options in config.php:
<syntaxhighlight lang="php">
$CFG->session_handler_class = '\core\session\memcached';
$CFG->session_memcached_save_path = '127.0.0.1:11211';
$CFG->session_memcached_prefix = 'memc.sess.key.';
$CFG->session_memcached_acquire_lock_timeout = 120;
$CFG->session_memcached_lock_expire = 7200; // Ignored if memcached extension <= 2.1.0
</syntaxhighlight>

Notes:
* Make sure the memcached server has enough memory.
* Use different prefix when storing sessions from multiple Moodle sites in one server.
* If PECL memcached extension version installed is less that 2.2.0, the locking works differently from other drivers - the lock is expired/released at the end of timeout - see MDL-42485.
* '''Don't use the same memcached server for both sessions and MUC. Events triggering MUC caches to be purged leads to MUC purging the memcached server - thus terminating ALL sessions.'''
* The <code php>$CFG->session_memcached_number_of_replicas</code> option is no longer supported.

For windows users, PHP.net only supplies binaries for memcache, (and not memcached). (http://windows.php.net/downloads/pecl/releases/)

(As of 2.7, two different contribs exist for memcache session handling - see MDL-42011 - it seems the OU one doesn't use prefix/lock_expire for some reason... possibly better to use the catalyst patch, where the only difference to the above config.php is the spelling of memcache(d).)

===File session driver===
This driver is used by default in new installation.

Configuration options in config.php:
<syntaxhighlight lang="php">
$CFG->session_handler_class = '\core\session\file';
$CFG->session_file_save_path = $CFG->dataroot.'/sessions';
</syntaxhighlight>

Notes:
* File based sessions require file system that supports file locking.

===Database session driver===
This type of driver was used by default in Moodle 2.0-2.5.

<syntaxhighlight lang="php">
$CFG->session_handler_class = '\core\session\database';
$CFG->session_database_acquire_lock_timeout = 120;
</syntaxhighlight>

Notes:
* DB sessions are not compatible with MyISAM database engine.
* If you are using MySQL/MariaDB make sure that \'max_allowed_packet\' in my.cnf (or my.ini) is at least 4M.
* The performance is relatively low, it is not recommended for large sites.

===Redis session driver===

The [[Redis]] session driver is available in Moodle 3.1.3 onwards (see MDL-54606). It requires a [[Redis_cache_store#Installing_Redis_server|Redis server]] and the [[Redis_cache_store#Installing_Redis_php_driver|Redis extension]].

Configuration options in config.php:
<syntaxhighlight lang="php">
$CFG->session_handler_class = '\core\session\redis';
$CFG->session_redis_host = '127.0.0.1';
$CFG->session_redis_port = 6379; // Optional.
$CFG->session_redis_database = 0; // Optional, default is db 0.
$CFG->session_redis_auth = ''; // Optional, default is don't set one.
$CFG->session_redis_prefix = ''; // Optional, default is don't set one.
$CFG->session_redis_acquire_lock_timeout = 120;
$CFG->session_redis_acquire_lock_retry = 100; // Optional, default is 100ms (from 3.9)
$CFG->session_redis_lock_expire = 7200;
$CFG->session_redis_serializer_use_igbinary = false; // Optional, default is PHP builtin serializer.
</syntaxhighlight>

Notes:
* Be careful on changing the default serializer: it requires <code php>--enable-redis-igbinary</code> at ''phpredis'' extension compile time '''and''' you need to remove '''the previous session data''' before using Moodle again.

== Read only sessions ==
There is an experimental feature introduced in Moodle 3.9 and stable in 3.11. It allows certain pages to start readonly sessions which do not require a write lock with the aim of high performance at scale.

https://tracker.moodle.org/browse/MDL-58018
=== Configuration ===
==== 1) Using a compliant session store ====
In order to use readonly sessions you need to be using a session store which supports it, which includes database and redis.
==== 2) Mapping session caches ===
By default all MUC 'session caches' are stored in the $SESSION which is a subtle distinction that is easily misunderstood. MUC caches can be read and written at any time and are independent of the $SESSION being locked. So all cache definitions which have a mode of session need to be mapped to a store which is not in the session such as in redis. If this isn't done errors will be raised highlighting the configuration issue.
==== 3) Turning it on in config.php ===
$CFG->enable_read_only_sessions = true;
If you have concerns about rolling this out, there is a soft rollout mode which report on any issues and you could leave this on for say a month or two and then turn it on fully:
$CFG->enable_read_only_sessions_debug = true;

==== 4) Adding support for it to core and plugins ====
Various critical pages and web services in core have been declared and implemented as readonly, if you want to support readonly sessions please read:
https://docs.moodle.org/dev/Session_locks

==See also==
* [[Sessions FAQ]]

[[cs:admin/setting/sessionhandling]]
[[ja:セッションハンドリング]]
[[de:Sitzungsinformationen]]
[[es:Manejo de la sesión]]
[[fr:Gestion des sessions]]

Session handling

2022-08-03T07:23:02Z

Brendanheywood: /* Read only sessions */

{{Server settings}}
An administrator can change the following settings in 'Session Handling' in the Site administration.

Once someone logs in to your Moodle server, the server starts a session. The session data allows the server to track users as they access different pages.

==Use database for session information==

Moodle needs to store the session data in some storage. By default either file or database session storage is selected, this option allows admin to change it. Large installation should use memcached driver described below.

Note that this option disappears after setting the $CFG->session_handler_class in config.php file.

==Timeout==

If users don't load a new page during the amount of time set here, Moodle will end their session and log them out.

Be sure this time frame is long enough to cover the longest test your teachers may offer. If a student is logged out while they are taking a test, their responses to the test questions may be lost.

==Cookie prefix==

Most of the time, you can leave this blank, unless you are running more than one Moodle site on the same server. In this case, you will want to customize the name of the cookie each Moodle site uses to track the session. This enables you to be logged into more than one Moodle site at the same time.

Note: If you change "Cookie prefix" or "Cookie path" you will need to login again as the changes take effect immediately.

==Cookie path==

The relative path to this Moodle installation, this may be used to force sending of Moodle session cookie to parent directories. Invalid values are ignored automatically.

==Cookie domain==

This can be used to send session cookies to higher domains instead of just the server domain. This may be useful for some SSO solutions. Invalid values are ignored automatically.

==Session drivers==
User sessions may be stored in different backends. Session drivers can be configured only in config.php file - see examples in config-dist.php file.

===Memcached session driver===
The Memcached session driver is the fastest driver. It requires external memcached server and memcached PHP extension. Server cluster nodes must use shared session storage.

Configuration options in config.php:
<syntaxhighlight lang="php">
$CFG->session_handler_class = '\core\session\memcached';
$CFG->session_memcached_save_path = '127.0.0.1:11211';
$CFG->session_memcached_prefix = 'memc.sess.key.';
$CFG->session_memcached_acquire_lock_timeout = 120;
$CFG->session_memcached_lock_expire = 7200; // Ignored if memcached extension <= 2.1.0
</syntaxhighlight>

Notes:
* Make sure the memcached server has enough memory.
* Use different prefix when storing sessions from multiple Moodle sites in one server.
* If PECL memcached extension version installed is less that 2.2.0, the locking works differently from other drivers - the lock is expired/released at the end of timeout - see MDL-42485.
* '''Don't use the same memcached server for both sessions and MUC. Events triggering MUC caches to be purged leads to MUC purging the memcached server - thus terminating ALL sessions.'''
* The <code php>$CFG->session_memcached_number_of_replicas</code> option is no longer supported.

For windows users, PHP.net only supplies binaries for memcache, (and not memcached). (http://windows.php.net/downloads/pecl/releases/)

(As of 2.7, two different contribs exist for memcache session handling - see MDL-42011 - it seems the OU one doesn't use prefix/lock_expire for some reason... possibly better to use the catalyst patch, where the only difference to the above config.php is the spelling of memcache(d).)

===File session driver===
This driver is used by default in new installation.

Configuration options in config.php:
<syntaxhighlight lang="php">
$CFG->session_handler_class = '\core\session\file';
$CFG->session_file_save_path = $CFG->dataroot.'/sessions';
</syntaxhighlight>

Notes:
* File based sessions require file system that supports file locking.

===Database session driver===
This type of driver was used by default in Moodle 2.0-2.5.

<syntaxhighlight lang="php">
$CFG->session_handler_class = '\core\session\database';
$CFG->session_database_acquire_lock_timeout = 120;
</syntaxhighlight>

Notes:
* DB sessions are not compatible with MyISAM database engine.
* If you are using MySQL/MariaDB make sure that \'max_allowed_packet\' in my.cnf (or my.ini) is at least 4M.
* The performance is relatively low, it is not recommended for large sites.

===Redis session driver===

The [[Redis]] session driver is available in Moodle 3.1.3 onwards (see MDL-54606). It requires a [[Redis_cache_store#Installing_Redis_server|Redis server]] and the [[Redis_cache_store#Installing_Redis_php_driver|Redis extension]].

Configuration options in config.php:
<syntaxhighlight lang="php">
$CFG->session_handler_class = '\core\session\redis';
$CFG->session_redis_host = '127.0.0.1';
$CFG->session_redis_port = 6379; // Optional.
$CFG->session_redis_database = 0; // Optional, default is db 0.
$CFG->session_redis_auth = ''; // Optional, default is don't set one.
$CFG->session_redis_prefix = ''; // Optional, default is don't set one.
$CFG->session_redis_acquire_lock_timeout = 120;
$CFG->session_redis_acquire_lock_retry = 100; // Optional, default is 100ms (from 3.9)
$CFG->session_redis_lock_expire = 7200;
$CFG->session_redis_serializer_use_igbinary = false; // Optional, default is PHP builtin serializer.
</syntaxhighlight>

Notes:
* Be careful on changing the default serializer: it requires <code php>--enable-redis-igbinary</code> at ''phpredis'' extension compile time '''and''' you need to remove '''the previous session data''' before using Moodle again.

== Read only sessions ==
There is an experimental feature introduced in Moodle 3.9 and stable in 3.11. It allows certain pages to start readonly sessions which do not require a write lock with the aim of high performance at scale.

https://tracker.moodle.org/browse/MDL-58018
=== Configuration ===
==== 1) Using a compliant session store ====
In order to use readonly sessions you need to be using a session store which supports it, which includes database and redis.
=== 2) Mapping session caches ===
By default all MUC 'session caches' are stored in the $SESSION which is a subtle distinction that is easily misunderstood. MUC caches can be read and written at any time and are independent of the $SESSION being locked. So all cache definitions which have a mode of session need to be mapped to a store which is not in the session such as in redis. If this isn't done errors will be raised highlighting the configuration issue.
=== 3) Turning it on in config.php ===
$CFG->enable_read_only_sessions = true;
If you have concerns about rolling this out, there is a soft rollout mode which report on any issues and you could leave this on for say a month or two and then turn it on fully:
$CFG->enable_read_only_sessions_debug = true;

==== 4) Adding support for it to core and plugins ====
Various critical pages and web services in core have been declared and implemented as readonly, if you want to support readonly sessions please read:
https://docs.moodle.org/dev/Session_locks

==See also==
* [[Sessions FAQ]]

[[cs:admin/setting/sessionhandling]]
[[ja:セッションハンドリング]]
[[de:Sitzungsinformationen]]
[[es:Manejo de la sesión]]
[[fr:Gestion des sessions]]

Server cluster

2021-06-23T12:08:38Z

Brendanheywood: $CFG->alternative_component_cache

This page is going to describe some basic information related to server clustering...

==Requirements==

* database server - ACID compliant, for example PostgreSQL and MariaDB
* main server that is able to share dataroot - locking support recommended, for example NFS
* load balancer - for example Nginx
* cluster nodes - web servers
* Redis (or Memcached) server for shared MUC caches

Note: this guide is not intended for Windows OS or any other Microsoft technologies.

==Initial installation==

# Perform standard CLI installation on the main server using shared database and dataroot directory.
# Setup web servers on cluster nodes - use local dirroot and shared database and dataroot.
# Configure load balancing.

==Related config.php settings==

===$CFG->wwwroot===
It must be the same on all nodes, it must be the public facing URL. It cannot be dynamic.

===$CFG->sslproxy===
Enable if you have https:// wwwroot but the SSL is done by load-balancer instead of web server.

Please note that it is not compatible with $CFG->loginhttps. This is because in order for loginhttps to work, we need to know the original request, and whether it was http or https. This allows us to only provide the login form over ssl. The original request is lost when made through a "reverse" proxy / load balancer, so we cannot determine what protocol the request was made in. So we can't provide most of moodle over http and the login page over https.

Enable ''Secure cookies only'' to make your site really secure, without it cookie stealing is still trivial.

===$CFG->reverseproxy===
Enable if your nodes are accessed via different URL.

Please note that it is not compatible with $CFG->loginhttps. This is because in order for loginhttps to work, we need to know the original request, and whether it was http or https. This allows us to only provide the login form over ssl. The original request is lost when made through a "reverse" proxy / load balancer, so we cannot determine what protocol the request was made in. So we can't provide most of moodle over http and the login page over https.

===$CFG->dirroot===
It is strongly recommended that $CFG->dirroot (which is automatically set via realpath(config.php)) contains the same path on all nodes. It does not need to point to the same shared directory though. The reason is that some some low level code may use the dirroot value for cache invalidation.

The simplest solution is to have the same directory structure on each cluster node and synchronise these during each upgrade.

The dirroot should be always read only for apache process because otherwise built in plugin installation and uninstallation would get the nodes out of sync.

===$CFG->dataroot===

This '''MUST''' be a shared directory where each cluster node is accessing the files directly. It must be very reliable, administrators cannot manipulate files directly.

Locking support is not required, if any code tries to use file locks in dataroot outside of cachedir or muc directory it is a bug.

===$CFG->alternative_file_system_class===

By default all uploaded content files are de-duplicated are stored inside [$CFG->dataroot]/filedir. But you can replace this is an alternative file store, like a cloud store such as AWS S3.

<code php>
$CFG->alternative_file_system_class = '\tool_objectfs\s3_file_system';
</code>

https://github.com/catalyst/moodle-tool_objectfs/

NOTE: Even if you use an alternate filesystem you '''MUST''' still have a shared $CFG->dataroot.

===$CFG->tempdir===

This directory '''MUST''' be shared by all cluster nodes. Locking is required.

===$CFG->cachedir===

This directory '''MUST''' be shared by all cluster nodes. Locking is required.

===$CFG->localcachedir===

The difference from $CFG->cachedir is that the directory does not have to be shared by all cluster nodes, the file contents do not change. Use local fast filesystem on each cluster node.

The nature of this path is very slow moving files that stay for a long time and are written once and never overwritten.

===$CFG->localrequestdir===

By default this is created inside /tmp or whatever sys_get_temp_dir() returns and is generally already local disk and not shared with other nodes. This directory holds temporary folders and files which only exist for the duration of a single http request. If you do change this use local fast filesystem on each cluster node.

===$CFG->backuptempdir===

Server clusters MUST use shared filesystem for backuptempdir! This directory gets very large and fast bursts of IO but files do not generally live here for any length of time. They are write heavy and do not have much contention.

===$CFG->alternative_component_cache===

This is used to cache a very low level representation of the components which Moodle uses. Because it is so low level it is before other higher level API's are available. It is always loaded on every request so putting this onto local disk is much better.

Typically the $CFG->alternative_component_cache = '/local/cache/dir/core_component.php' would point to local node cache directory.

NOTE: Before upgrade the administrator MUST have to manually execute following on each node:

<code>
$ php admin/cli/alternative_component_cache.php --rebuild
</code>

Alternatively you could put the cache file directly into dirroot and distribute it together with new PHP source files. Yet another possibility would be to purge all local caches on all nodes before upgrade or simply change the script name in config.php on all nodes before upgrade. Or this could be built into new containers as part of your CI / CD deployment.

''Implemented in Moodle 2.6, see MDL-40475.''

==Performance recommendations==

#Use OPcache extension on all cluster nodes.
#Set $CFG->localcachedir to fast local filesystem on each node.
#Use one big central memcached server for all shared caches that support it.
#Use local memcached instances on cluster nodes for local caches that support it.
#Store user sessions in one shared server eg Redis. (See [[Session_handling]] for details)
#Use fast local directory for dirroot on each cluster node.
#Use dynamic cluster node management.
#Use transparent proxy servers.

==Upgrade procedure==

#Disable load balancer.
#Upgrade dirroot files on master server.
#Perform CLI upgrade.
#Manually reset all caches in cluster nodes - restart web server, delete localcachedir and temp directories, restart memcached, etc. Or delete all cluster nodes and create nodes from a new template.
#Enable load balancer.

==Step by step guide for server clustering in Moodle 2.6==
From hardware and performance forum thread [https://moodle.org/mod/forum/discuss.php?d=251547 https://moodle.org/mod/forum/discuss.php?d=251547]

* 1 Determine your specific need for caches. This involves the concepts of shared cache or local cache, disk based cache or server based cache or protocol specific cache like Memcached or MongoDB.
** 1.1 If you have a slow shared disk, you might benefit from a local disk cache.
** 1.2 If you have only a few users on your Moodle site, you might not want to set up a Memcached service, even if the acceleration that Memcached provides, is very significant for the user experience.
** 1.3 If you want to do anything in your power for accelerating the site, you might consider MongoDB.
* 2 Configure the caches, test them and verify them. There is room for improvement in the examples for cache configuration. This is probably the most difficult step.
* 3 Install the cache support on server level. This may involve installing php modules or config for php modules.
* 4 Create a cache instance in MUC here: example.com/cache/admin.php?action=addstore&plugin=memcached
** 4.1 Give the cache instance some arbitrary name.
** 4.2 All other fields have a question mark that can be clicked on for excellent help that tells you what to fill in, and the syntax (very important).
** 4.3 The result should be a Configured Store Instance, with the name of your choice.
* 5 The final step is to deploy the created cache instances by Editing Mappings for e.g. Language string cache in the list of Known cache definitions.
** 5.1 While experimenting with this, I have found it a life saver to open a separate browser window, where the default setting is selected, so I just need to click on the Save button to revert the setting, just in case I lose contact with the site.
** 5.2 Select the name of your configured store instance from the dropdown list and click on the Save button.
** 5.3 Test the new cache setting. If you lose contact with the site or it behaves weirdly, try using the trick in step 1. In case of emergency you might remove the cache config file (muc/config.php) in the folder pointed to by $CFG->dataroot . It seems that Moodle writes a new default config file if it is missing.

==See also==
*[[Performance recommendations]]
*[[Caching]]
*[[:dev:Server clustering improvements proposal]]
*Hardware and performance forum thread [https://moodle.org/mod/forum/discuss.php?d=251547https://moodle.org/mod/forum/discuss.php?d=251547]
*How to Cluster Moodle on Multiple Servers for High Availability and Scalability [http://www.severalnines.com/blog/clustering-moodle-multiple-servers-high-availability-scalability]
* PHP session cache in a cluster
** https://www.digitalocean.com/community/tutorials/how-to-set-up-a-redis-server-as-a-session-handler-for-php-on-ubuntu-14-04
** https://inchoo.net/magento/programming-magento/session-storage-php

Mail configuration

2021-06-14T12:11:17Z

Brendanheywood: /* The most common setup */

{{Server settings}}
==Outgoing mail configuration==

Settings related to mail sent by Moodle can be found in 'Outgoing mail configuration' in Site administration -> Server -> Email.

The setting 'Allowed email domains' (allowedemaildomains) allows you to enter domains allowed by your mail server so that forum post notification emails can be sent from users' real addresses. It accepts a wildcard for conveniently adding a lot of domains (*.example.com - tim@first.example.com), or a strict match (example.com - tim@example.com).

If allowed domains are set then the user's email address will be used in the "From" and "Reply to" field only in the following situations:

* The email matches the allowed domains, and the user's setting is to display their email address to everyone.
* The email matches the allowed domains, and the user's setting is to display their email only to course members, and the email is to be delivered to a course member.

All other situations use the no-reply address.

The setting 'Email via information' (emailfromvia) adds via information in the From section of outgoing email to inform the recipient where the email came from:
Name (via shortname) <noreplyaddress>
'shortname' is the short name for the site as set in the front page settings.

NOTE: You can also use [[Email_setup_gmail|Google gMail]] servers or AMAZON [https://docs.bitnami.com/aws/how-to/use-ses/ AWS SES] Simple Email Services to setup SMTP relay for your outbound emails.

=== DKIM ===

For advanced DKIM setup this is usually done at the MTA such as postfix eg using a 'milter' like opendkim.

However there are advantages to doing this in Moodle directly such as when you have limited control over the way your email is being sent. Also by having it in Moodle it can be easier to manage.

In 3.10 / 4.0 a new setting was added that makes it possible to sign emails at the Moodle level and it requires setting up the private certificates and putting them in a known location where Moodle can find them. Because emails could be sent from a variety of From email addresses the location contains the domain in it's path and you can provide as many certificates as needed but this is an uncommon use case.

==== The most common setup ====

The simplest and fairly typical setup is where all emails are sent from the noreply email. In this setup we will give instructions on a linux setup such as debian or ubuntu.

<code php>
$CFG->noreplyaddress = 'noreply@moodle.myschool.edu.au'
</code>

In this case you need to choose a DKIM selector which is arbitrary but is often based on a date as the best practice is to rotate them on a periodic basis.

Lets say we have chosen a selector of '2020sep'.

Now in sitedata we need to create a folder to hold the DKIM certificate with a subdirectory matching the domain:

<code php>
mkdir -p /path/to/sitedata/dkim/moodle.myschool.edu.au
</code>

Next in this directory generate the private key and public key DNS record using the opendkim-genkey tool:

<code php>
opendkim-genkey -b 2048 -r -s 2020sep -d moodle.myschool.edu.au -v
</code>

This should result in two files like this:

<code php>
/path/to/sitedata/dkim/moodle.myschool.edu.au/2020sep.txt
/path/to/sitedata/dkim/moodle.myschool.edu.au/2020sep.private
</code>

Only the .private file is used by Moodle, the .txt file is the TXT record which you need to add to your DNS. To confirm that it is all correct there is a great public tool where you can enter the domain and DKIM selector and it will confirm the record looks like it is in the correct shape.

https://mxtoolbox.com/dkim.aspx

Once this is in place then use the email testing tool in moodle to send a test email, it can be useful to turn on the debugsmtp setting.

/admin/testoutgoingmailconf.php

You should see the DKIM signature in the email headers. The email server receiving the email should also have validated this signature as well and added another header with the results of this validation.

ie in Gmail open the email, click the '...' on the right, then 'Show original' and in the headers it should say:

DKIM: 'PASS' with domain moodle.myschool.edu.au

===Test outgoing mail configuration===

A link is available to send yourself a test email to check everything is working correctly.

==Incoming mail configuration==
If incoming mail processing is enabled in 'Incoming mail configuration' in Site administration, then users are able to reply to forum posts via email and send files to their private files as email attachments.

===Mailbox configuration===
It is important to have a dedicated email address here. Don't use one you normally use for your personal emails. You do not need to add the @ sign. If you have set up the email mountorangeschool @ besteveremail.com then it would be entered as in the following screenshot:
[[File:emailexampleincoming.png|thumb|center|400px]]

===Incoming mail server settings===
As an example, if you are using gmail you would use '''IMAP.gmail.com''' in the Incoming mail server (messageinbound_host) field. (If using gmail you also need to make sure that you've enabled IMAP for yor gmail account - see https://support.google.com/mail/troubleshooter/1668960?hl=en )

Note1: The SMTP server hosting the mailbox you've configured above must support ''plus addressing'' i.e. any email sent to mountorangeschool+blahblahblah@besteveremail.com is still delivered to mountorangeschool@besteveremail.com.

Note2 : The username and password here must relate to the settings you entered earlier in Mailbox configuration. So if your address was mountorangeschool @ besteveremail.com and your username is ''mountorangeschool'', then enter your username in this section along with the password you use to get into this email account.

Note 3: You may also need to make sure that your host does not block outbound connections to the IMAP ports (some do by default).

Note 4: If using gmail, you may find that IMAP does not work with Google's higher security setting. If IMAP is not working with gmail, check out https://support.google.com/accounts/answer/6010255?hl=en-GB

==Message handlers==

===Email to Private files===
*If you enable this, then users will be able to send attachments via email directly to their private files. See [[Private files]] for details of how the feature works.
*Each user will be provided with an address in their Private files to which they send the email and attached files. You can set the default expiry period for this address here.
*Checking the 'Validate sender address' box will mean that if an email is sent to a user's private files from a different account from that registered with user in Moodle, then Moodle will check first before allowing the file to be stored in the user's Private files.

===Invalid recipient handler===
If a valid message is received but the sender cannot be authenticated, the message is stored on the email server and the user is contacted using the email address in their user profile. The user is given the chance to reply to confirm the authenticity of the original message.This handler processes those replies.

It is not possible to disable sender verification of this handler because the user may reply from an incorrect email address if their email client configuration is incorrect.

===Reply to forum posts===
*If you enable this, then users will be able to reply to forum posts directly from their email inbox. See the section on 'Reply to posts via email' in [[Using Forum]] for details of how the feature works.
*You must leave empty the ''Site administration > Server > Email > Outgoing mail configuration > Allowed email domains'' setting; otherwise users will see the email of the forum poster instead.
*Each user will be provided with reply-to address when they click to reply to a forum post via email. You can set the default expiry period for this address here.

==See also==
* [https://moodle.org/mod/forum/discuss.php?d=277594 Need help configuring forum's "Reply to post" feature] forum discussion

[[es:Configuración del correo]]
[[de:Einstellungen für E-Mails]]

[[Category:Forum]]

Mail configuration

2021-06-14T12:11:02Z

Brendanheywood:

{{Server settings}}
==Outgoing mail configuration==

Settings related to mail sent by Moodle can be found in 'Outgoing mail configuration' in Site administration -> Server -> Email.

The setting 'Allowed email domains' (allowedemaildomains) allows you to enter domains allowed by your mail server so that forum post notification emails can be sent from users' real addresses. It accepts a wildcard for conveniently adding a lot of domains (*.example.com - tim@first.example.com), or a strict match (example.com - tim@example.com).

If allowed domains are set then the user's email address will be used in the "From" and "Reply to" field only in the following situations:

* The email matches the allowed domains, and the user's setting is to display their email address to everyone.
* The email matches the allowed domains, and the user's setting is to display their email only to course members, and the email is to be delivered to a course member.

All other situations use the no-reply address.

The setting 'Email via information' (emailfromvia) adds via information in the From section of outgoing email to inform the recipient where the email came from:
Name (via shortname) <noreplyaddress>
'shortname' is the short name for the site as set in the front page settings.

NOTE: You can also use [[Email_setup_gmail|Google gMail]] servers or AMAZON [https://docs.bitnami.com/aws/how-to/use-ses/ AWS SES] Simple Email Services to setup SMTP relay for your outbound emails.

=== DKIM ===

For advanced DKIM setup this is usually done at the MTA such as postfix eg using a 'milter' like opendkim.

However there are advantages to doing this in Moodle directly such as when you have limited control over the way your email is being sent. Also by having it in Moodle it can be easier to manage.

In 3.10 / 4.0 a new setting was added that makes it possible to sign emails at the Moodle level and it requires setting up the private certificates and putting them in a known location where Moodle can find them. Because emails could be sent from a variety of From email addresses the location contains the domain in it's path and you can provide as many certificates as needed but this is an uncommon use case.

=== The most common setup ===

The simplest and fairly typical setup is where all emails are sent from the noreply email. In this setup we will give instructions on a linux setup such as debian or ubuntu.

<code php>
$CFG->noreplyaddress = 'noreply@moodle.myschool.edu.au'
</code>

In this case you need to choose a DKIM selector which is arbitrary but is often based on a date as the best practice is to rotate them on a periodic basis.

Lets say we have chosen a selector of '2020sep'.

Now in sitedata we need to create a folder to hold the DKIM certificate with a subdirectory matching the domain:

<code php>
mkdir -p /path/to/sitedata/dkim/moodle.myschool.edu.au
</code>

Next in this directory generate the private key and public key DNS record using the opendkim-genkey tool:

<code php>
opendkim-genkey -b 2048 -r -s 2020sep -d moodle.myschool.edu.au -v
</code>

This should result in two files like this:

<code php>
/path/to/sitedata/dkim/moodle.myschool.edu.au/2020sep.txt
/path/to/sitedata/dkim/moodle.myschool.edu.au/2020sep.private
</code>

Only the .private file is used by Moodle, the .txt file is the TXT record which you need to add to your DNS. To confirm that it is all correct there is a great public tool where you can enter the domain and DKIM selector and it will confirm the record looks like it is in the correct shape.

https://mxtoolbox.com/dkim.aspx

Once this is in place then use the email testing tool in moodle to send a test email, it can be useful to turn on the debugsmtp setting.

/admin/testoutgoingmailconf.php

You should see the DKIM signature in the email headers. The email server receiving the email should also have validated this signature as well and added another header with the results of this validation.

ie in Gmail open the email, click the '...' on the right, then 'Show original' and in the headers it should say:

DKIM: 'PASS' with domain moodle.myschool.edu.au

===Test outgoing mail configuration===

A link is available to send yourself a test email to check everything is working correctly.

==Incoming mail configuration==
If incoming mail processing is enabled in 'Incoming mail configuration' in Site administration, then users are able to reply to forum posts via email and send files to their private files as email attachments.

===Mailbox configuration===
It is important to have a dedicated email address here. Don't use one you normally use for your personal emails. You do not need to add the @ sign. If you have set up the email mountorangeschool @ besteveremail.com then it would be entered as in the following screenshot:
[[File:emailexampleincoming.png|thumb|center|400px]]

===Incoming mail server settings===
As an example, if you are using gmail you would use '''IMAP.gmail.com''' in the Incoming mail server (messageinbound_host) field. (If using gmail you also need to make sure that you've enabled IMAP for yor gmail account - see https://support.google.com/mail/troubleshooter/1668960?hl=en )

Note1: The SMTP server hosting the mailbox you've configured above must support ''plus addressing'' i.e. any email sent to mountorangeschool+blahblahblah@besteveremail.com is still delivered to mountorangeschool@besteveremail.com.

Note2 : The username and password here must relate to the settings you entered earlier in Mailbox configuration. So if your address was mountorangeschool @ besteveremail.com and your username is ''mountorangeschool'', then enter your username in this section along with the password you use to get into this email account.

Note 3: You may also need to make sure that your host does not block outbound connections to the IMAP ports (some do by default).

Note 4: If using gmail, you may find that IMAP does not work with Google's higher security setting. If IMAP is not working with gmail, check out https://support.google.com/accounts/answer/6010255?hl=en-GB

==Message handlers==

===Email to Private files===
*If you enable this, then users will be able to send attachments via email directly to their private files. See [[Private files]] for details of how the feature works.
*Each user will be provided with an address in their Private files to which they send the email and attached files. You can set the default expiry period for this address here.
*Checking the 'Validate sender address' box will mean that if an email is sent to a user's private files from a different account from that registered with user in Moodle, then Moodle will check first before allowing the file to be stored in the user's Private files.

===Invalid recipient handler===
If a valid message is received but the sender cannot be authenticated, the message is stored on the email server and the user is contacted using the email address in their user profile. The user is given the chance to reply to confirm the authenticity of the original message.This handler processes those replies.

It is not possible to disable sender verification of this handler because the user may reply from an incorrect email address if their email client configuration is incorrect.

===Reply to forum posts===
*If you enable this, then users will be able to reply to forum posts directly from their email inbox. See the section on 'Reply to posts via email' in [[Using Forum]] for details of how the feature works.
*You must leave empty the ''Site administration > Server > Email > Outgoing mail configuration > Allowed email domains'' setting; otherwise users will see the email of the forum poster instead.
*Each user will be provided with reply-to address when they click to reply to a forum post via email. You can set the default expiry period for this address here.

==See also==
* [https://moodle.org/mod/forum/discuss.php?d=277594 Need help configuring forum's "Reply to post" feature] forum discussion

[[es:Configuración del correo]]
[[de:Einstellungen für E-Mails]]

[[Category:Forum]]

Mail configuration

2021-06-14T12:10:40Z

Brendanheywood: Added DKIM section

{{Server settings}}
==Outgoing mail configuration==

Settings related to mail sent by Moodle can be found in 'Outgoing mail configuration' in Site administration -> Server -> Email.

The setting 'Allowed email domains' (allowedemaildomains) allows you to enter domains allowed by your mail server so that forum post notification emails can be sent from users' real addresses. It accepts a wildcard for conveniently adding a lot of domains (*.example.com - tim@first.example.com), or a strict match (example.com - tim@example.com).

If allowed domains are set then the user's email address will be used in the "From" and "Reply to" field only in the following situations:

* The email matches the allowed domains, and the user's setting is to display their email address to everyone.
* The email matches the allowed domains, and the user's setting is to display their email only to course members, and the email is to be delivered to a course member.

All other situations use the no-reply address.

The setting 'Email via information' (emailfromvia) adds via information in the From section of outgoing email to inform the recipient where the email came from:
Name (via shortname) <noreplyaddress>
'shortname' is the short name for the site as set in the front page settings.

NOTE: You can also use [[Email_setup_gmail|Google gMail]] servers or AMAZON [https://docs.bitnami.com/aws/how-to/use-ses/ AWS SES] Simple Email Services to setup SMTP relay for your outbound emails.

== DKIM ==

For advanced DKIM setup this is usually done at the MTA such as postfix eg using a 'milter' like opendkim.

However there are advantages to doing this in Moodle directly such as when you have limited control over the way your email is being sent. Also by having it in Moodle it can be easier to manage.

In 3.10 / 4.0 a new setting was added that makes it possible to sign emails at the Moodle level and it requires setting up the private certificates and putting them in a known location where Moodle can find them. Because emails could be sent from a variety of From email addresses the location contains the domain in it's path and you can provide as many certificates as needed but this is an uncommon use case.

== The most common setup ==

The simplest and fairly typical setup is where all emails are sent from the noreply email. In this setup we will give instructions on a linux setup such as debian or ubuntu.

<code php>
$CFG->noreplyaddress = 'noreply@moodle.myschool.edu.au'
</code>

In this case you need to choose a DKIM selector which is arbitrary but is often based on a date as the best practice is to rotate them on a periodic basis.

Lets say we have chosen a selector of '2020sep'.

Now in sitedata we need to create a folder to hold the DKIM certificate with a subdirectory matching the domain:

<code php>
mkdir -p /path/to/sitedata/dkim/moodle.myschool.edu.au
</code>

Next in this directory generate the private key and public key DNS record using the opendkim-genkey tool:

<code php>
opendkim-genkey -b 2048 -r -s 2020sep -d moodle.myschool.edu.au -v
</code>

This should result in two files like this:

<code php>
/path/to/sitedata/dkim/moodle.myschool.edu.au/2020sep.txt
/path/to/sitedata/dkim/moodle.myschool.edu.au/2020sep.private
</code>

Only the .private file is used by Moodle, the .txt file is the TXT record which you need to add to your DNS. To confirm that it is all correct there is a great public tool where you can enter the domain and DKIM selector and it will confirm the record looks like it is in the correct shape.

https://mxtoolbox.com/dkim.aspx

Once this is in place then use the email testing tool in moodle to send a test email, it can be useful to turn on the debugsmtp setting.

/admin/testoutgoingmailconf.php

You should see the DKIM signature in the email headers. The email server receiving the email should also have validated this signature as well and added another header with the results of this validation.

ie in Gmail open the email, click the '...' on the right, then 'Show original' and in the headers it should say:

DKIM: 'PASS' with domain moodle.myschool.edu.au

===Test outgoing mail configuration===

A link is available to send yourself a test email to check everything is working correctly.

==Incoming mail configuration==
If incoming mail processing is enabled in 'Incoming mail configuration' in Site administration, then users are able to reply to forum posts via email and send files to their private files as email attachments.

===Mailbox configuration===
It is important to have a dedicated email address here. Don't use one you normally use for your personal emails. You do not need to add the @ sign. If you have set up the email mountorangeschool @ besteveremail.com then it would be entered as in the following screenshot:
[[File:emailexampleincoming.png|thumb|center|400px]]

===Incoming mail server settings===
As an example, if you are using gmail you would use '''IMAP.gmail.com''' in the Incoming mail server (messageinbound_host) field. (If using gmail you also need to make sure that you've enabled IMAP for yor gmail account - see https://support.google.com/mail/troubleshooter/1668960?hl=en )

Note1: The SMTP server hosting the mailbox you've configured above must support ''plus addressing'' i.e. any email sent to mountorangeschool+blahblahblah@besteveremail.com is still delivered to mountorangeschool@besteveremail.com.

Note2 : The username and password here must relate to the settings you entered earlier in Mailbox configuration. So if your address was mountorangeschool @ besteveremail.com and your username is ''mountorangeschool'', then enter your username in this section along with the password you use to get into this email account.

Note 3: You may also need to make sure that your host does not block outbound connections to the IMAP ports (some do by default).

Note 4: If using gmail, you may find that IMAP does not work with Google's higher security setting. If IMAP is not working with gmail, check out https://support.google.com/accounts/answer/6010255?hl=en-GB

==Message handlers==

===Email to Private files===
*If you enable this, then users will be able to send attachments via email directly to their private files. See [[Private files]] for details of how the feature works.
*Each user will be provided with an address in their Private files to which they send the email and attached files. You can set the default expiry period for this address here.
*Checking the 'Validate sender address' box will mean that if an email is sent to a user's private files from a different account from that registered with user in Moodle, then Moodle will check first before allowing the file to be stored in the user's Private files.

===Invalid recipient handler===
If a valid message is received but the sender cannot be authenticated, the message is stored on the email server and the user is contacted using the email address in their user profile. The user is given the chance to reply to confirm the authenticity of the original message.This handler processes those replies.

It is not possible to disable sender verification of this handler because the user may reply from an incorrect email address if their email client configuration is incorrect.

===Reply to forum posts===
*If you enable this, then users will be able to reply to forum posts directly from their email inbox. See the section on 'Reply to posts via email' in [[Using Forum]] for details of how the feature works.
*You must leave empty the ''Site administration > Server > Email > Outgoing mail configuration > Allowed email domains'' setting; otherwise users will see the email of the forum poster instead.
*Each user will be provided with reply-to address when they click to reply to a forum post via email. You can set the default expiry period for this address here.

==See also==
* [https://moodle.org/mod/forum/discuss.php?d=277594 Need help configuring forum's "Reply to post" feature] forum discussion

[[es:Configuración del correo]]
[[de:Einstellungen für E-Mails]]

[[Category:Forum]]

Installing Moodle

2021-05-31T23:34:10Z

Brendanheywood: Add link to apache

{{Template:Installing Moodle}}
''This page explains how to install Moodle. If you are an expert and/or in a hurry try [[Installation Quickstart]].''

If you just want to try Moodle on a standalone machine there are 'one-click' installers for Windows (see [[Complete install packages for Windows]]) and for OSX (see [[Complete Install Packages for Mac OS X]]) or [[ install on OS X]]. These are unsuitable for production servers.

If you want to avoid installing Moodle yourself completely, consider https://moodle.com/moodlecloud/

== Requirements ==

Moodle is primarily developed in Linux using [[Apache]], [[PostgreSQL]]/[[MySQL]]/[[MariaDB]] and [[PHP]] (sometimes known as the LAMP platform). Typically this is also how Moodle is run, although there are other options as long as the software requirements of the [{{Release notes}} release] are met.

If you are installing Moodle in a Windows server, note that from php5.5 onwards, you will also need to have the Visual C++ Redistributable for Visual Studio 2012 installed from:
http://www.microsoft.com/en-us/download/details.aspx?id=30679 Visual C++] ( x86 or x64)

The basic requirements for Moodle are as follows:

=== Hardware ===
* Disk space: 200MB for the Moodle code, plus as much as you need to store content. 5GB is probably a realistic minimum.
* Processor: 1GHz (min), 2GHz dual core or more recommended.
* Memory: 512MB (min), 1GB or more is recommended. 8GB plus is likely on a large production server
* Consider separate servers for the web "front ends" and the database. It is much easier to "tune"

All the above requirements will vary depending on specific hardware and software combinations as well as the type of use and load; busy sites may well require additional resources. Further guidance can be found under [[Performance_recommendations|performance recommendations]]. Moodle scales easily by increasing hardware.

For very large sites, you are much better starting with a small pilot and gaining some experience and insight. A "what hardware do I need for 50,000 user?" style post in the forums is highly unlikely to get a useful answer.

=== Software ===

See the [{{Release notes}} release notes] in the dev docs for software requirements.

== Set up your server ==

Depending on the use case a Moodle server may be anything from a Desktop PC (e.g. for testing and evaluating) to a rackmounted or [[Server cluster|clustered]] solution to cloud VMs or other hosted solutions. As mentioned above there are lots of possibilities for installing the basic server software, for details see:

* [[Installing AMP]]
* [[Internet_Information_Services|IIS]]
* [[Nginx]]
* [[Apache]]

It will help hugely, regardless of your deployment choices, if time is taken to understand how to configure the different parts of your software stack (HTTP daemon, database, PHP etc). Do not expect the standard server configuration to be optimal for Moodle. For example, the web server and database servers will almost certainly require tuning to get the best out of Moodle.

If a hosting provider is being used ensure that all Moodle [{{Release notes}}#Server_requirements requirements] (such as PHP version) are met by the hosting platform before attempting the installation. It will help to become familiar with changing settings within the hosting provider's platform (e.g. PHP file upload maximums) as the options and tools provided vary.

== Download and copy files into place ==

'''IMPORTANT: While there are now a number of places you can get the Moodle code (including host provided Moodle installers), you are strongly advised to only obtain Moodle from moodle.org. If you run into problems it will be a great deal easier to support you.'''

You have two options:
* Download your required version from http://moodle.org/downloads and unzip/unpack...
* '''OR''' Pull the code from the Git repository (recommended for developers and also makes upgrading very simple):
<pre>
$ git clone -b MOODLE_{{Version3}}_STABLE git://git.moodle.org/moodle.git
</pre>

For a fuller discussion see [[Git for Administrators]].

Either of the above should result in a directory called '''moodle''', containing a number of files and folders.

You can typically place the whole folder in your web server documents directory, in which case the site will be located at '''<nowiki>http://yourwebserver.com/moodle</nowiki>''', or you can copy all the contents straight into the main web server documents directory, in which case the site will be simply '''<nowiki>http://yourwebserver.com</nowiki>'''. See the documentation for your system and/or web server if you are unsure.

:''Tip:'' If you are downloading Moodle to your local computer and then uploading it to your hosted web site, it is usually better to upload the compressed Moodle file and then decompress on your hosted web site. If you decompress Moodle on your local computer, because Moodle is comprised of over 25,000 files, trying to upload over 25,000 files using an FTP client or your host's "file manager" can sometimes miss a file and cause errors.

* '''Secure the Moodle files:''' It is vital that the files are not writeable by the web server user. For example, on Unix/Linux (as root):
<pre>
chown -R root /path/to/moodle
chmod -R 0755 /path/to/moodle
</pre>
(files are owned by the administrator/superuser and are only writeable by them - readable by everyone else)

On test/dev sites you ''may'' want to make the files writeable in order to use the built-in plugin installer. This is discouraged for live sites (at least, revert to more secure settings if you do).

== Create an empty database ==

Next create a new, empty database for your installation. You need to find and make a note of following information for use during the final installation stage:
* '''dbhost''' - the database server hostname. Probably ''localhost'' if the database and web server are the same machine, otherwise the name of the database server
* '''dbname''' - the database name. Whatever you called it, e.g. ''moodle''
* '''dbuser''' - the username for the database. Whatever you assigned, e.g. ''moodleuser'' - do not use the root/superuser account. Create a proper account with the minimum permissions needed.
* '''dbpass''' - the password for the above user

If your site is hosted you should find a web-based administration page for databases as part of the control panel (or ask your administrator). For everyone else or for detailed instructions, see the page for your chosen database server:
* [[PostgreSQL]]
* [[MariaDB]]
* [[MySQL]]
* [[MSSQL]]
* [[Oracle]] (not recommended)

== Create the (''moodledata'') data directory ==

Moodle requires a directory to store all of its files (all your site's uploaded files, temporary data, cache, session data etc.). The web server needs to be able to write to this directory. On larger systems consider how much free space you are going to use when allocating this directory.

Due to the default way Moodle caches data you may have serious performance issues if you use relatively slow storage (e.g. NFS) for this directory. Read the [[Performance_recommendations]] carefully and consider using (e.g.) redis or memcached for [[Caching]].

'''IMPORTANT:''' This directory must '''NOT''' be accessible directly via the web. This would be a serious security hole. Do not try to place it inside your web root or inside your Moodle program files directory. Moodle will not install. It can go anywhere else convenient.

Here is an example (Unix/Linux) of creating the directory and setting the permissions for '''anyone''' on the server to write here. This is only appropriate for Moodle servers that are not shared. Discuss this with your server administrator for better permissions that just allow the web server user to access these files.

<pre>
# mkdir /path/to/moodledata
# chmod 0777 /path/to/moodledata
</pre>

==== Securing moodledata in a web directory ====

If you are using a hosted site and you have no option but to place 'moodledata' in a web accessible directory. You may be able to secure it by creating an .htaccess file in the 'moodledata' directory. This does not work on all systems - see your host/administrator. Create a file called .htaccess containing only the following lines:

'''Apache 2.2'''
<pre>
order deny,allow
deny from all
</pre>

'''Apache 2.4'''
<pre>
Require all denied
</pre>

== Start Moodle install ==
It's now time to run the installer to create the database tables and configure your new site. The recommended method is to use the command line installer. If you cannot do this for any reason (e.g. on a Windows server) the web-based installer is still available.

=== Command line installer ===

It's best to run the command line as your system's web user. You need to know what that is - see your system's documentation (e.g. Ubuntu/Debian is 'www-data', Centos is 'apache')

* Example of using the command-line (as root - substitute 'www-data' for your web user):
<pre>
# chown www-data /path/to/moodle
# cd /path/to/moodle/admin/cli
# sudo -u www-data /usr/bin/php install.php
# chown -R root /path/to/moodle
</pre>
The chowns allow the script to write a new config.php file. More information about the options can be found using
<pre>
# php install.php --help
</pre>

You will be asked for other settings that have not been discussed on this page - if unsure just accept the defaults. For a full discussion see [[Administration via command line]]

=== Web based installer ===

For ease of use you can install Moodle via the web. We recommend configuring your web server so that the page is not publicly accessible until the installation is complete.

To run the web installer script, just go to your Moodle's main URL using a web browser.

The installation process will take you through a number of pages. You should be asked to confirm the copyright, see the database tables being created, supply administrator account details and supply the site details. The database creation can take some time - please be patient. You should eventually end up at the Moodle front page with an invitation to create a new course.

It is very likely that you will be asked to download the new config.php file and upload it to your Moodle installation - just follow the on-screen instructions.

==Final configuration==

=== Settings within Moodle ===
There are a number of options within the Moodle Site Administration screens (accessible from the 'Site administration' tab in the 'Administration' block (Classic theme) or the Site administration button in the navigation bar (Boost). Here are a few of the more important ones that you will probably want to check:
* ''Administration > Site administration > Server > Email > [[Mail_configuration#Outgoing_mail_configuration|Outgoing mail configuration]]'': Set your smtp server and authentication if required (so your Moodle site can send emails). You can also set a norepy email on this page.
* ''Administration > Site administration > Server > Server > Support contact''. Set your support contact email.
* ''Administration > Site administration > Server > System paths'': Set the paths to du, dot and aspell binaries.
* ''Administration > Site administration > Server > HTTP'': If you are behind a firewall you may need to set your proxy credentials in the 'Web proxy' section.
* ''Administration > Site administration > Location > Update timezones'': Run this to make sure your timezone information is up to date. (more info [[Location]])
** [http://php.net/manual/en/timezones.php Set server's local timezone] inside <tt>php.ini</tt> (should probably be inside <tt>/etc/php.ini</tt> or <tt>/etc/php.d/date.ini</tt>, depending on the underlying OS):
<code php>
[Date]
; Defines the default timezone used by the date functions
date.timezone = "YOUR LOCAL TIMEZONE"
</code>

=== Remaining tasks ===

* '''Configure Cron''': Moodle's background tasks (e.g. sending out forum emails and performing course backups) are performed by a script which you can set to execute at specific times of the day. This is known as a cron script. Please refer to the [[Cron|Cron instructions]].
* '''Set up backups''': See [[Site backup]] and [[Automated course backup]].
* '''Secure your Moodle site''': Read the [[Security recommendations]].
*'''Increasing the maximum upload size''' See [[Installation FAQ]] Maximum upload file size - how to change it?
* '''Check mail works''' : From Site administration > Server > Test outgoing mail configuration, use the link to send yourself a test email. Don't be tempted to skip this step.

=== Installation is complete :) ===

* Create a new course: You can now access Moodle through your web browser (using the same URL as you set during the install process), log in as your admin user and creatse a new course. See [[Adding a new course|create a new course]].

=== If something goes wrong... ===

Here are some things you should try...

* Check the [[Installation FAQ]]
* Check your file permissions carefully. Can your web server read (but not write) the Moodle program files? Can your web server read and write your Moodle data directory? If you don't fully understand how file ownership and permissions work on your operating system it would be time very well spent to find out.
* Check your database permissions. Have you set up your database user with the correct rights and permissions for your configuration (especially if the web server and database server are different machines)?
* Create your [[Configuration file]] (config.php) by hand. Copy config-dist.php (in the root of the Moodle program directory) to config.php, edit it and set your database/site options there. Installation will continue from the right place.
* Once you have a config.php (see previous tip) you can edit it to turn on debugging (in section 8). This may give you extra information to help track down a problem. If you have access, check your web server error log(s).
* Re-check your php.ini / .htaccess settings. Are they appropriate (e.g. memory_limit), did you edit the correct php.ini / .htaccess file and (if required) did you re-start the web server after making changes?
* Did you include any non-core (optional) plugins, themes or other code before starting the installation script? If so, remove it and try again (it may be broken or incompatible).
* Explain your problem in the [http://moodle.org/mod/forum/view.php?id=28 Installation problems forum]. '''PLEASE''' list your software versions; explain what you did, what happened and what error messages you saw (if any); explain what you tried. There is no such thing as 'nothing', even a blank page is something!

== Platform specific instructions ==

'''Note:''' Much of this information is provided by the community. It may not have been checked and may be out of date. Please read in conjunction with the above installation instructions.

* [[Windows installation]]
** [[Installing Moodle on SmarterASP.NET]]
* [[Unix or Linux Installation]]
* [[Mac Installation]]
* [[Amazon EC2 Cloud Services Installation]]

== See also ==
* [http://www.slideshare.net/gb2048/my-own-moodle Slideshare presentation by Gareth Barnard on installing a local installation of Moodle] and accompanying [https://drive.google.com/folderview?id=0B17B0rYH2zERU21sQnVweUZCUFk&usp=sharing help guides]
* [http://moodle.org/mod/forum/discuss.php?d=182086 New Video Tutorial- How to Install Moodle on Shared Hosting via cPanel (Not Fantastico)]
* [https://moodle.org/mod/forum/discuss.php?d=401983 Another one for cPanel using videos]
* [http://moodle.org/mod/forum/discuss.php?d=199542 Video Tutorial - Install Moodle on a Virtual Box from scratch]

[[es:Instalaci%C3%B3n_de_moodle]]
[[de:Installation von Moodle]]
[[fr:Installation de Moodle]]
[[ja:Moodleのインストール]]

Performance recommendations

2021-05-31T12:13:30Z

Brendanheywood: /* Read replicas */

{{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 has had 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).

It can be interesting to install and use the [https://moodle.org/plugins/report_benchmark Benchmark plugin] in order to find the bottlenecks of your system that specifically affect Moodle.

==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 and cache areas (see [[Caching]]), 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.

On very large, load-balanced, systems the performance of the shared components become critical. It's important that your shared file areas are properly tuned and that you use an effective cache (Redis is highly recommended). A good understanding of these areas of system administration should be considered a minimum requirement.

===Server cluster===

Using Moodle forum discussions:

*[http://moodle.org/mod/forum/discuss.php?d=57202 Moodle clustering]
*[http://moodle.org/mod/forum/discuss.php?d=44470 Software load balancing]
*[http://moodle.org/mod/forum/discuss.php?d=49986 TCP load balancing]
*[http://moodle.org/mod/forum/discuss.php?d=88214 Installation for 3000 simultaneous users]

==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 (e.g. 4GB or more). 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.
* If your 'moodledata' area is going to be on relatively slow storage (e.g. NFS mount on to a NAS device) you will have performance issues with the default cache configuration (which writes to this storage). See the page on [[Caching]] and choose an alternative. Redis is recommended. Using [https://en.wikipedia.org/wiki/GlusterFS GlusterFS] / [https://en.wikipedia.org/wiki/OCFS2 OCFS2] / [https://en.wikipedia.org/wiki/GFS2 GFS2] on a [https://en.wikipedia.org/wiki/Storage_Area_Network SAN] device and [https://en.wikipedia.org/wiki/Fibre_Channel Fiber Channel] could improve performance (See more info on the Moodle [https://moodle.org/mod/forum/discuss.php?d=214680#p1123124 forum thread], [https://moodle.org/mod/forum/discuss.php?d=310501#p1242382 NFS performance tuing] )
* 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.
* 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 [https://moodle.org/mod/forum/discuss.php?d=310501#p1242382 "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], full text [http://developer.yahoo.com/performance/rules.html Best Practices for Speeding Up Your Web Site], <strike>([http://video.yahoo.com/video/play?vid=1040890 video])</strike> for fast loading websites.

===PHP performance===
* PHP contains a built-in accelerator. Make sure it is enabled.
* 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/IIS6 ISAPI module''' (rather than a CGI). IIS 7.0/7.5 (Windows Server 2008/R2) users should choose a FastCGI installation for best performance.
* Also check the '''memory_limit''' in php.ini. The default value for the memory_limit directive is 128M. On some sites, it may need to be larger - especially for some backup operations.
* Also see [[PHP_settings_by_Moodle_version]]
* Use [http://blog.bitnami.com/2014/06/performance-enhacements-for-apache-and.html PHP-FPM] (with apache).

===Install HowTo===
==== APC ====
* [http://2bits.com/articles/installing-php-apc-gnulinux-centos-5.html APC on CentOS 5.x (linux)]
* [http://fplanque.com/dev/linux/install-apc-php-cache-debian-lenny APC on Debian (linux)]
==== eAccelerator ====
* [http://noveckg.blogspot.com/2010/02/installing-eaccelerator-cache-for-php.html Installing eAccelerator on CentOS 5.x (linux)]
* [https://docs.moodle.org/en/Installing_eAccelerator_In_Ubuntu_Server/ Installing eAccelerator on Ubuntu Server (linux)]
==== MemCached ====
Memcached server (daemon)
* [https://www.tecmint.com/install-memcached-on-centos-7/ Installing Memcached on CentOS 7.x (linux)] (as of php 7.x, only memcached is available)
* [https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-memcached-on-centos-7 How To Install and Secure Memcached on CentOS 7]
* [https://wiki.zimbra.com/wiki/Blocking_Memcached_Attack#Iptables_rules_for_Redhat_based_servers Iptables rules for Redhat based servers]
Memcached PHP 7.1 extension
* [https://dl.iuscommunity.org/pub/ius/stable/CentOS/7/x86_64/repoview/php71u-pecl-memcached.html php71u-pecl-memcached] from IUS CentOS 7.x repository.

===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 '''MaxRequestWorkers''' directive correctly ('''MaxClients''' before Apache 2.4). Use this formula to help (which uses 80% of available memory to leave room for spare):
MaxRequestWorkers = Total available memory * 80% / Max memory usage of apache process
:Memory usage of apache process is usually 10MB but Moodle can easily use up to 100MB per process, so a general rule of thumb is to divide your available memory in megabytes by 100 to get a conservative setting for MaxClients. You are quite likely to find yourself lowering the MaxRequestWorkers from its default of 150 on a Moodle server. To get a more accurate estimate read the value from the shell command:
#ps -ylC httpd --sort:rss

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

:'''Warning''': Do not be tempted to set the value of MaxRequestWorkers 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 '''MaxConnectionsPerChild''' ('''MaxRequestsPerChild''' before Apache 2.4) 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

* Compression reduces response times by reducing the size of the HTTP response
# Install and enable mod_deflate - 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_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/x-js text/javascript text/css application/javascript
</ifmodule>
* Use Apache [http://blog.bitnami.com/2014/06/performance-enhacements-for-apache-and.html event] [http://httpd.apache.org/docs/current/mpm.html MPM] (and not the default Prefork or Worker)

===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, NginX and Cherokee performance===
You can increase server performance by using a '''light-weight''' webserver like [http://www.lighttpd.net/ lighttpd], [http://nginx.net/ nginx] or [http://www.cherokee-project.com/ cherokee] 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.

Do note that these are likely to be the least tested server environments of all particularly if you are using advanced features such as web services and/or Moodle Networking. They are probably best considered for heavily used Moodle sites with relatively simple configurations.

===X-Sendfile===

X-Sendfile modules improve performance when sending large files from Moodle. It is recommended to configure your web server and Moodle to use this feature if available.

Configure web server:
* Apache - https://tn123.org/mod_xsendfile/
* Lighttpd - http://redmine.lighttpd.net/projects/lighttpd/wiki/X-LIGHTTPD-send-file
* Nginx - http://wiki.nginx.org/XSendfile

Enable support in config.php (see config-dist.php):
<code php>
// $CFG->xsendfile = 'X-Sendfile'; // Apache {@see https://tn123.org/mod_xsendfile/}
// $CFG->xsendfile = 'X-LIGHTTPD-send-file'; // Lighttpd {@see http://redmine.lighttpd.net/projects/lighttpd/wiki/X-LIGHTTPD-send-file}
// $CFG->xsendfile = 'X-Accel-Redirect'; // Nginx {@see http://wiki.nginx.org/XSendfile}
</code>

Configure file location prefixes if your server implementation requires it:
<code php>
// $CFG->xsendfilealiases = array(
// '/dataroot/' => $CFG->dataroot,
// '/cachedir/' => '/var/www/moodle/cache', // for custom $CFG->cachedir locations
// '/localcachedir/' => '/var/local/cache', // for custom $CFG->localcachedir locations
// '/tempdir/' => '/var/www/moodle/temp', // for custom $CFG->tempdir locations
// '/filedir' => '/var/www/moodle/filedir', // for custom $CFG->filedir locations
// );
</code>

== Cron performance ==

Cron is a very important part of the overall performance of moodle as many asynchronous processes are offloaded to cron, so it needs to be running and have enough through put to handle the work being given to it by the front ends.

See [[Cron_with_Unix_or_Linux#High_performance_cron_tasks]]

==Database performance==

===MySQL performance===

The '''number one thing''' you can do to improve MySQL performance is to read, understand and implement the recommendations in the [https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html Innodb Buffer Pool] article.

The [https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool-resize.html buffer pool size] can safely be changed while your server is running, as long as your server has enough memory (RAM) to accommodate the value you set. On a machine that is dedicated to MySQL, you can safely set this value to 80% of available memory.

Consider setting [https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_buffer_pool_instances innodb_buffer_pool_instances] to the number of cores, vCPUs, or chips you have available. Adjust this value in accordance with the recommendations in the [https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool-resize.html MySQL documentation].

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.pl/ 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.

===PostgreSQL performance===

There are some good papers around on tuning PostgreSQL (like [http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server this one]), 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.

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/GeneralBits/Tidbits/index.php

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

* Splitting '''mdl_log''' to several tables and using a VIEW with UNION to read them as one. (See Tim Hunt [https://moodle.org/mod/forum/discuss.php?d=243531#p1104165 explanation] on the Moodle forums)

=== Read replicas ===

Since Moodle 3.9 you can configure read replica's to be used where possible. For very large systems as much as 80-90% of the DB load can be moved away from the primary. For configuration see config-dist:

https://github.com/moodle/moodle/blob/master/config-dist.php#L84-L117

===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 [http://moodle.org/mod/forum/discuss.php?d=49195 how to migrate from MySQL to PostgreSQL] (forum discussion).
* [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.

==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 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/cli/cron.php'') efficiency can be much improved.
* The '''Recent activities''' block is consuming too many resources if you have huge number of records <code>mdl_log</code>. This is being tested to optimize the SQL query.
* The '''Quiz''' module is known to stretch database performance. However, it has been getting better in recent versions, and we don't know of any good, up-to-date performance measurements. (Here is a [http://moodle.org/mod/forum/discuss.php?d=68579 case study from 2007 with 300 quiz users].). The following suggestions were described by [https://moodle.org/user/view.php?id=94615&course=5 Al Rachels] in [https://moodle.org/mod/forum/discuss.php?d=347126 this forum thread]:
** make sure both Moodle, and the operating system, are installed on a [https://en.wikipedia.org/wiki/Solid-state_drive solid state drive]
** upgrade to and use [https://docs.moodle.org/dev/Moodle_and_PHP7 PHP 7]
** run MySQLTuner and implement its recommendations

See [[Performance settings]] for more information on performance-related Moodle settings.

==See also==

*Using Moodle: [http://moodle.org/mod/forum/view.php?f=94 Hardware and Performance] forum
*[http://opensourceelearning.blogspot.be/2012/10/why-your-moodle-site-is-slow-five.html Why Your Moodle Site is Slow: Five Simple Settings] blog post from Jonathan Moore
*I teach with Moodle perfomance testing: http://www.iteachwithmoodle.com/2012/11/17/moodle-2-4-beta-performance-test-comparison-with-moodle-2-3/
*[http://jfilip.ca/2013/08/20/moodle-2-4-5-vs-2-5-1-performance-and-muc-apc-cache-store/ Moodle 2.4.5 vs 2.5.2 performance and MUC APC cahe store]
*[http://jfilip.ca/2013/09/25/moodle-performance-testing-2-4-6-vs-2-5-2-vs-2-6dev/ Moodle performance testing 2.4.6 vs 2.5.2 vs 2.6dev]
*[http://jfilip.ca/2013/09/24/moodle-performance-analysis-revisted-now-with-mariadb/ Moodle performance analysis revisited (now with MariaDB)]
*[http://tjhunt.blogspot.ca/2013/05/performance-testing-moodle.html Tim Hunt's blog (May 2, 2013) on performance testing Moodle]
*[http://newrelic.com/ New Relic, Application Performance Monitoring]
*[http://blog.bitnami.com/2014/06/performance-enhacements-for-apache-and.html Performance enhacements for Apache and PHP (Apache Event MPM and PHP-FPM)]
*[https://scholarlms.net/performance-recommendations/ Performance recommendations]
*[https://enovation.ie/moodle-performance-investigation-using-performance-info/ Moodle performance investigation – using performance info ]

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]
* [https://moodle.org/mod/forum/discuss.php?d=240391#unread Advice on optimising php/db code in moodle2+]
* [https://moodle.org/mod/forum/discuss.php?d=243531 Moodle 2.5 performance testing at the OU]
* [https://moodle.org/mod/forum/discuss.php?d=273602 100 active users limit with 4vCPU]
* [https://moodle.org/mod/forum/discuss.php?d=336603#p1356423 Performance Tip ... shared...]

[[es:Recomendaciones sobre desempeño]]
[[fr:Recommandations_de_performance]]
[[ja:パフォーマンス]]
[[de:Geschwindigkeitsempfehlungen]]

Performance recommendations

2021-05-31T12:13:16Z

Brendanheywood: Add section on read replicas

{{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 has had 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).

It can be interesting to install and use the [https://moodle.org/plugins/report_benchmark Benchmark plugin] in order to find the bottlenecks of your system that specifically affect Moodle.

==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 and cache areas (see [[Caching]]), 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.

On very large, load-balanced, systems the performance of the shared components become critical. It's important that your shared file areas are properly tuned and that you use an effective cache (Redis is highly recommended). A good understanding of these areas of system administration should be considered a minimum requirement.

===Server cluster===

Using Moodle forum discussions:

*[http://moodle.org/mod/forum/discuss.php?d=57202 Moodle clustering]
*[http://moodle.org/mod/forum/discuss.php?d=44470 Software load balancing]
*[http://moodle.org/mod/forum/discuss.php?d=49986 TCP load balancing]
*[http://moodle.org/mod/forum/discuss.php?d=88214 Installation for 3000 simultaneous users]

==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 (e.g. 4GB or more). 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.
* If your 'moodledata' area is going to be on relatively slow storage (e.g. NFS mount on to a NAS device) you will have performance issues with the default cache configuration (which writes to this storage). See the page on [[Caching]] and choose an alternative. Redis is recommended. Using [https://en.wikipedia.org/wiki/GlusterFS GlusterFS] / [https://en.wikipedia.org/wiki/OCFS2 OCFS2] / [https://en.wikipedia.org/wiki/GFS2 GFS2] on a [https://en.wikipedia.org/wiki/Storage_Area_Network SAN] device and [https://en.wikipedia.org/wiki/Fibre_Channel Fiber Channel] could improve performance (See more info on the Moodle [https://moodle.org/mod/forum/discuss.php?d=214680#p1123124 forum thread], [https://moodle.org/mod/forum/discuss.php?d=310501#p1242382 NFS performance tuing] )
* 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.
* 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 [https://moodle.org/mod/forum/discuss.php?d=310501#p1242382 "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], full text [http://developer.yahoo.com/performance/rules.html Best Practices for Speeding Up Your Web Site], <strike>([http://video.yahoo.com/video/play?vid=1040890 video])</strike> for fast loading websites.

===PHP performance===
* PHP contains a built-in accelerator. Make sure it is enabled.
* 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/IIS6 ISAPI module''' (rather than a CGI). IIS 7.0/7.5 (Windows Server 2008/R2) users should choose a FastCGI installation for best performance.
* Also check the '''memory_limit''' in php.ini. The default value for the memory_limit directive is 128M. On some sites, it may need to be larger - especially for some backup operations.
* Also see [[PHP_settings_by_Moodle_version]]
* Use [http://blog.bitnami.com/2014/06/performance-enhacements-for-apache-and.html PHP-FPM] (with apache).

===Install HowTo===
==== APC ====
* [http://2bits.com/articles/installing-php-apc-gnulinux-centos-5.html APC on CentOS 5.x (linux)]
* [http://fplanque.com/dev/linux/install-apc-php-cache-debian-lenny APC on Debian (linux)]
==== eAccelerator ====
* [http://noveckg.blogspot.com/2010/02/installing-eaccelerator-cache-for-php.html Installing eAccelerator on CentOS 5.x (linux)]
* [https://docs.moodle.org/en/Installing_eAccelerator_In_Ubuntu_Server/ Installing eAccelerator on Ubuntu Server (linux)]
==== MemCached ====
Memcached server (daemon)
* [https://www.tecmint.com/install-memcached-on-centos-7/ Installing Memcached on CentOS 7.x (linux)] (as of php 7.x, only memcached is available)
* [https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-memcached-on-centos-7 How To Install and Secure Memcached on CentOS 7]
* [https://wiki.zimbra.com/wiki/Blocking_Memcached_Attack#Iptables_rules_for_Redhat_based_servers Iptables rules for Redhat based servers]
Memcached PHP 7.1 extension
* [https://dl.iuscommunity.org/pub/ius/stable/CentOS/7/x86_64/repoview/php71u-pecl-memcached.html php71u-pecl-memcached] from IUS CentOS 7.x repository.

===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 '''MaxRequestWorkers''' directive correctly ('''MaxClients''' before Apache 2.4). Use this formula to help (which uses 80% of available memory to leave room for spare):
MaxRequestWorkers = Total available memory * 80% / Max memory usage of apache process
:Memory usage of apache process is usually 10MB but Moodle can easily use up to 100MB per process, so a general rule of thumb is to divide your available memory in megabytes by 100 to get a conservative setting for MaxClients. You are quite likely to find yourself lowering the MaxRequestWorkers from its default of 150 on a Moodle server. To get a more accurate estimate read the value from the shell command:
#ps -ylC httpd --sort:rss

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

:'''Warning''': Do not be tempted to set the value of MaxRequestWorkers 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 '''MaxConnectionsPerChild''' ('''MaxRequestsPerChild''' before Apache 2.4) 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

* Compression reduces response times by reducing the size of the HTTP response
# Install and enable mod_deflate - 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_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/x-js text/javascript text/css application/javascript
</ifmodule>
* Use Apache [http://blog.bitnami.com/2014/06/performance-enhacements-for-apache-and.html event] [http://httpd.apache.org/docs/current/mpm.html MPM] (and not the default Prefork or Worker)

===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, NginX and Cherokee performance===
You can increase server performance by using a '''light-weight''' webserver like [http://www.lighttpd.net/ lighttpd], [http://nginx.net/ nginx] or [http://www.cherokee-project.com/ cherokee] 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.

Do note that these are likely to be the least tested server environments of all particularly if you are using advanced features such as web services and/or Moodle Networking. They are probably best considered for heavily used Moodle sites with relatively simple configurations.

===X-Sendfile===

X-Sendfile modules improve performance when sending large files from Moodle. It is recommended to configure your web server and Moodle to use this feature if available.

Configure web server:
* Apache - https://tn123.org/mod_xsendfile/
* Lighttpd - http://redmine.lighttpd.net/projects/lighttpd/wiki/X-LIGHTTPD-send-file
* Nginx - http://wiki.nginx.org/XSendfile

Enable support in config.php (see config-dist.php):
<code php>
// $CFG->xsendfile = 'X-Sendfile'; // Apache {@see https://tn123.org/mod_xsendfile/}
// $CFG->xsendfile = 'X-LIGHTTPD-send-file'; // Lighttpd {@see http://redmine.lighttpd.net/projects/lighttpd/wiki/X-LIGHTTPD-send-file}
// $CFG->xsendfile = 'X-Accel-Redirect'; // Nginx {@see http://wiki.nginx.org/XSendfile}
</code>

Configure file location prefixes if your server implementation requires it:
<code php>
// $CFG->xsendfilealiases = array(
// '/dataroot/' => $CFG->dataroot,
// '/cachedir/' => '/var/www/moodle/cache', // for custom $CFG->cachedir locations
// '/localcachedir/' => '/var/local/cache', // for custom $CFG->localcachedir locations
// '/tempdir/' => '/var/www/moodle/temp', // for custom $CFG->tempdir locations
// '/filedir' => '/var/www/moodle/filedir', // for custom $CFG->filedir locations
// );
</code>

== Cron performance ==

Cron is a very important part of the overall performance of moodle as many asynchronous processes are offloaded to cron, so it needs to be running and have enough through put to handle the work being given to it by the front ends.

See [[Cron_with_Unix_or_Linux#High_performance_cron_tasks]]

==Database performance==

===MySQL performance===

The '''number one thing''' you can do to improve MySQL performance is to read, understand and implement the recommendations in the [https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html Innodb Buffer Pool] article.

The [https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool-resize.html buffer pool size] can safely be changed while your server is running, as long as your server has enough memory (RAM) to accommodate the value you set. On a machine that is dedicated to MySQL, you can safely set this value to 80% of available memory.

Consider setting [https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_buffer_pool_instances innodb_buffer_pool_instances] to the number of cores, vCPUs, or chips you have available. Adjust this value in accordance with the recommendations in the [https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool-resize.html MySQL documentation].

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.pl/ 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.

===PostgreSQL performance===

There are some good papers around on tuning PostgreSQL (like [http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server this one]), 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.

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/GeneralBits/Tidbits/index.php

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

* Splitting '''mdl_log''' to several tables and using a VIEW with UNION to read them as one. (See Tim Hunt [https://moodle.org/mod/forum/discuss.php?d=243531#p1104165 explanation] on the Moodle forums)

=== Read replicas ===

{{Moodle 3.9}}

Since Moodle 3.9 you can configure read replica's to be used where possible. For very large systems as much as 80-90% of the DB load can be moved away from the primary. For configuration see config-dist:

https://github.com/moodle/moodle/blob/master/config-dist.php#L84-L117

===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 [http://moodle.org/mod/forum/discuss.php?d=49195 how to migrate from MySQL to PostgreSQL] (forum discussion).
* [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.

==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 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/cli/cron.php'') efficiency can be much improved.
* The '''Recent activities''' block is consuming too many resources if you have huge number of records <code>mdl_log</code>. This is being tested to optimize the SQL query.
* The '''Quiz''' module is known to stretch database performance. However, it has been getting better in recent versions, and we don't know of any good, up-to-date performance measurements. (Here is a [http://moodle.org/mod/forum/discuss.php?d=68579 case study from 2007 with 300 quiz users].). The following suggestions were described by [https://moodle.org/user/view.php?id=94615&course=5 Al Rachels] in [https://moodle.org/mod/forum/discuss.php?d=347126 this forum thread]:
** make sure both Moodle, and the operating system, are installed on a [https://en.wikipedia.org/wiki/Solid-state_drive solid state drive]
** upgrade to and use [https://docs.moodle.org/dev/Moodle_and_PHP7 PHP 7]
** run MySQLTuner and implement its recommendations

See [[Performance settings]] for more information on performance-related Moodle settings.

==See also==

*Using Moodle: [http://moodle.org/mod/forum/view.php?f=94 Hardware and Performance] forum
*[http://opensourceelearning.blogspot.be/2012/10/why-your-moodle-site-is-slow-five.html Why Your Moodle Site is Slow: Five Simple Settings] blog post from Jonathan Moore
*I teach with Moodle perfomance testing: http://www.iteachwithmoodle.com/2012/11/17/moodle-2-4-beta-performance-test-comparison-with-moodle-2-3/
*[http://jfilip.ca/2013/08/20/moodle-2-4-5-vs-2-5-1-performance-and-muc-apc-cache-store/ Moodle 2.4.5 vs 2.5.2 performance and MUC APC cahe store]
*[http://jfilip.ca/2013/09/25/moodle-performance-testing-2-4-6-vs-2-5-2-vs-2-6dev/ Moodle performance testing 2.4.6 vs 2.5.2 vs 2.6dev]
*[http://jfilip.ca/2013/09/24/moodle-performance-analysis-revisted-now-with-mariadb/ Moodle performance analysis revisited (now with MariaDB)]
*[http://tjhunt.blogspot.ca/2013/05/performance-testing-moodle.html Tim Hunt's blog (May 2, 2013) on performance testing Moodle]
*[http://newrelic.com/ New Relic, Application Performance Monitoring]
*[http://blog.bitnami.com/2014/06/performance-enhacements-for-apache-and.html Performance enhacements for Apache and PHP (Apache Event MPM and PHP-FPM)]
*[https://scholarlms.net/performance-recommendations/ Performance recommendations]
*[https://enovation.ie/moodle-performance-investigation-using-performance-info/ Moodle performance investigation – using performance info ]

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]
* [https://moodle.org/mod/forum/discuss.php?d=240391#unread Advice on optimising php/db code in moodle2+]
* [https://moodle.org/mod/forum/discuss.php?d=243531 Moodle 2.5 performance testing at the OU]
* [https://moodle.org/mod/forum/discuss.php?d=273602 100 active users limit with 4vCPU]
* [https://moodle.org/mod/forum/discuss.php?d=336603#p1356423 Performance Tip ... shared...]

[[es:Recomendaciones sobre desempeño]]
[[fr:Recommandations_de_performance]]
[[ja:パフォーマンス]]
[[de:Geschwindigkeitsempfehlungen]]

Apache

2021-05-24T23:08:26Z

Brendanheywood:

{{Installing Moodle}}
'''This article refers to the 'Apache HTTP server''''

The Apache HTTP server is the software that (along with the PHP scripting language) 'runs' Moodle. Note that there are alternatives (e.g. IIS on Windows, Nginx on Linux, MacOS) but the Apache HTTP Server is very popular on all platforms.

== Installing Apache ==
Installers are available for most platforms from http://httpd.apache.org/download.cgi. The official installation instructions are here: http://httpd.apache.org/docs/2.0/install.html. If you are running Linux then you are recommended to use the packaged version if you can. For example, in Debian/Ubuntu it is simply:
<pre>
sudo apt-get install apache2
</pre>

See the documentation for your particular platform for the instructions. Apache is straightforward to build from source if you have to and the PHP documentation contains an article on building both Apache and PHP together - although you should rarely need to do that.

==Performance==

See [[Performance recommendations]]

==Slasharguments==

The function ''slash arguments'' is required for various features in Moodle to work correctly, as described in [[Using slash arguments]].

To turn it on, add this line to your ''httpd.conf'', or to a ''.htaccess'' file in your local directory:

<code php>
AcceptPathInfo On
</code>

''Note:'' When using ".htaccess" in your local Moodle install folder, you may need to include/enable "AllowOverride Directive" in "httpd.conf", first.

''Note:'' Using .htaccess file will cause performance hit on your server!

If you are using Ionos (formerly 1&1) shared webhosting, the above does not work, there is a known bug when using PHP as CGI. The solution is to create a php.ini file in the moodle directory with this content:

<code php>
cgi.fix_pathinfo = 0
</code>

Also Ionos requires that this php.ini be in every directory that a script executes. Use the procedure below to link a php.ini in every subdirectory back to your original php.ini file.

<code php>
cd your_moodle_directory
find -type d -exec ln -s $PWD/php.ini {}/php.ini \;
</code>

Source: [https://www.ionos.com/help/hosting/using-php-for-web-projects/applying-php-settings-to-all-subdirectories/ Ionos php.ini Help]

This may affect other shared hosting providers as well.

== Handling 40x errors ==

This enables missing files to be themed by Moodle

<pre>
ErrorDocument 404 /error/index.php

# This sends any 403 from apache through to the same page, but also
# overrides the http status with 404 instead for better security.
ErrorDocument 403 /error/index.php?code=404
</pre>

== Hiding internal paths ==

<pre>
RewriteEngine On

# RewriteRule "(\/vendor\/)" - [F]
# RewriteRule "(\/node_modules\/)" - [F]
# RewriteRule "(^|/)\.(?!well-known\/)" - [F]
# RewriteRule "(composer\.json)" - [F]
# RewriteRule "(\.lock)" - [F]
# RewriteRule "(\/environment.xml)" - [F]
# Options -Indexes
# RewriteRule "(\/install.xml)" - [F]
# RewriteRule "(\/README)" - [F]
# RewriteRule "(\/readme)" - [F]
# RewriteRule "(\/moodle_readme)" - [F]
# RewriteRule "(\/upgrade\.txt)" - [F]
# RewriteRule "(phpunit\.xml\.dist)" - [F]
# RewriteRule "(\/tests\/behat\/)" - [F]
# RewriteRule "(\/fixtures\/)" - [F]
</pre>

==SSL==

Moodle has an option to enable HTTPS for the whole site or for just the login pages; either option requires that your web server is configured for SSL.

* Whole site HTTPS is enabled by changing http://<url> to https:// <url> in your config.php 'wwwroot' parameter.
* Login only HTTPS is enabled by setting the 'loginhttps' parameter, where the wwwroot schema should remain as http://

NOTE: Login only https was deprecated and removed from Moodle 3.4: https://tracker.moodle.org/browse/MDL-42834

Login only https is available in Moodle 3.3 and earlier in the admin interface via Administration>Security>HTTP Security and checking the button. (Note the warning and see ssl section below)

Prior to Moodle 2.3 It was not advised to run the whole site over HTTPS due to legacy restrictions with client-side caching. This is no longer the case assuming client browsers support the 'Cache-Control: public' method, which all supported browsers for this version of Moodle do.

To use HTTPS you will need to obtain an SSL certificate, you have two options:

* Generate a self-signed certificate. This is fine on (say) an Intranet but unsuitable for the public internet, but users will we warned the certificated is untrusted when used publicly.
* Purchase a certificate from a vendor. There is a surprising range of prices and value-added services available. Some hosting companies even provide free certificates.

Debian provides instructions for installing a self-signed certificate [https://wiki.debian.org/Self-Signed_Certificate on their wiki] and includes general information on configuring Apache for SSL.
If you purchase a vendor certificate you will normally receive instructions for installing it.

A basic Apache SSL configuration can be summarised as:

Listen 443
NameVirtualHost *:443
<VirtualHost *:443>
SSLEngine On
SSLCertificateFile /path/to/your/certificate.crt
SSLCertificateKeyFile /path/to/your/certificate.key
...
</VirtualHost>

== See also ==

* [http://httpd.apache.org/ The Apache HTTP Server Project homepage]
* [http://en.wikipedia.org/wiki/Apache_HTTP_Server Wikipedia article on the Apache HTTP Server]
* [http://httpd.apache.org/docs/2.0/misc/perf-tuning.html Apache Performance Tuning article at the official homepage]
* [https://els.earlham.edu/cayaraa/weblog/1468.html Making Moodle work with SSL]
* [http://www.krufix.de/ Using the same Moodle twice in local network and Internet via SSL-Proxy] (in German)

[[pl:Apache]]
[[ja:Apache]]
[[de:Apache]]
[[es:Apache]]

Mall:Installing Moodle

2021-05-24T09:33:52Z

Brendanheywood:

<div class="navtrail">[[Main page]] ► [[Installation]] ► [[{{PAGENAME}}]]</div>
<div class="sideblock right" style="width: 16em;">
<div class="header">[[Installation]]</div>
<div class="content">
*[[Installing Moodle]]
*[[Installation quick guide]]
*[[Cron]]
*[[Nginx]]
*[[Apache]]
*[[Internet_Information_Services]]
*[[Installing plugins]]
*[[Installation FAQ]]
*[[Upgrading]]
*[[Upgrade overview]]
*[[Automatic updates deployment]]
*[[Git for Administrators|Git guide]]
*[[Administration via command line]]
*[[Upgrading FAQ]]
*[[Moodle migration]]
</div>
</div>

<includeonly>[[Category:Installation]]</includeonly>
<noinclude>This template will categorise articles that include it into [[:Category:Installation]].</noinclude>

Nginx

2021-05-24T09:27:09Z

Brendanheywood: /* XSendfile aka X-Accel-Redirect */

{{Installing Moodle}}[[Nginx]] [engine x] is an HTTP and reverse proxy server, as well as a mail proxy server, written by Igor Sysoev. The nginx project started with a strong focus on high concurrency, high performance and low memory usage. It is licensed under the 2-clause BSD-like license and it runs on Linux, BSD variants, Mac OS X, Solaris, AIX, HP-UX, as well as on other *nix flavours. It also has a proof of concept port for Microsoft Windows.

''The following is community-contributed documentation on Nginx configuration. Amendments and additions are welcome.''

== Nginx configuration ==

=== PHP-FPM ===

Nginx is usually configured to interface with PHP via [http://php.net/manual/en/install.fpm.php php-fpm]. This is both fast and robust.

PHP-FPM's default behaviour for pools is usually to restrict the execution of scripts to a specific extension, i.e. .php. You should ensure that this behaviour is configured within your particular package/distribution, e.g. for debian,

'''/etc/php5/fpm/pool.d/www.conf'''
security.limit_extensions = .php

=== Nginx ===

Add the following 'slash arguments' compatible 'location' block to your vhosts 'server' in your nginx configuration (further explanation at '[[Using slash arguments]]').

'''nginx.conf location:'''
<pre>
location ~ [^/]\.php(/|$) {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_index index.php;
fastcgi_pass 127.0.0.1:9000 (or your php-fpm socket);
include fastcgi_params;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
</pre>

If the above does not work try the following:
Note: This was for CentOS 7.6 (1804), MariaDB 10.3, Nginx 1.15 and PHP 7.3.5
<pre>
location ~ ^(.+\.php)(.*)$ {
root /usr/share/nginx/html/moodle/;
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_index index.php;
fastcgi_pass 127.0.0.1:9000;
include /etc/nginx/mime.types;
include fastcgi_params;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
</pre>

If you find that this does not work (scripts, styles, and images not loading) '''and''' that there are <code>open() "..." failed (20: Not a directory)</code> lines appearing in your logs: Check whether there are any directives related to static content '''before''' this block and try moving them '''after''' this block.

Another potential pitfall is the use of '''try_files'''. Many guides recommend configurations like <pre>try_files $fastcgi_script_name =404;</pre>. But if try_files is used, nginx deletes the content of the '''$fastcgi_path_info''' variable (this is [https://trac.nginx.org/nginx/ticket/321 intended behavior]). This causes '''PATH_INFO''' to also be empty, so slash arguments don't work.
An alternative is the use of <pre>if(!-f $document_root$fastcgi_script_name) {return 404;}</pre> [https://www.nginx.com/resources/wiki/start/topics/examples/phpfcgi/#connecting-nginx-to-php-fpm as recommended] by the nginx documentation, although the nginx documentation also recommends [https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/ not using if].

==== Error pages ====

<pre>
# This passes 404 pages to Moodle so they can be themed
error_page 404 /error/index.php; error_page 403 =404 /error/index.php;
</pre>

==== Hiding internal files ====

<pre>
# Hide all dot files but allow "Well-Known URIs" as per RFC 5785
location ~ /\.(?!well-known).* {
return 404;
}

# This should be after the php fpm rule and very close to the last nginx ruleset.
# Don't allow direct access to various internal files. See MDL-69333
location ~ (/vendor/|/node_modules/|composer\.json|/readme|/README|readme\.txt|/upgrade\.txt|db/install\.xml|/fixtures/|/behat/|phpunit\.xml|\.lock|environment\.xml) {
deny all;
return 404;
}
</pre>

==== XSendfile aka X-Accel-Redirect ====

Setting Moodle and Nginx to use XSendfile functionality is a big win as it frees PHP from delivering files allowing Nginx to do what it does best, i.e. deliver files.

Enable xsendfile for Nginx in Moodles config.php, this is documented in the config-dist.php, a minimal configuration look like this,
<pre>
$CFG->xsendfile = 'X-Accel-Redirect';
$CFG->xsendfilealiases = array(
'/dataroot/' => $CFG->dataroot
);
</pre>
Accompany this with a matching 'location' block in your nginx server configuration.
<pre>
location /dataroot/ {
internal;
alias <full_moodledata_path>; # ensure the path ends with /
}
</pre>
The definition of 'internal' here is '''critical''' as it prevents client access to your dataroot.

== See also ==

* Real <tt>PATH_INFO</tt> support:
** https://moodle.org/mod/forum/discuss.php?d=278916
** https://moodle.org/mod/forum/discuss.php?d=307388
* '''[Deprecated]''' Internal rewriting to the HTTP GET <tt>file</tt> parameter:
** https://moodle.org/mod/forum/discuss.php?d=83445

[[Category:Installation]]

[[es:Nginx]]
[[pt-br:Nginx]]

Nginx

2021-05-24T09:26:54Z

Brendanheywood:

{{Installing Moodle}}[[Nginx]] [engine x] is an HTTP and reverse proxy server, as well as a mail proxy server, written by Igor Sysoev. The nginx project started with a strong focus on high concurrency, high performance and low memory usage. It is licensed under the 2-clause BSD-like license and it runs on Linux, BSD variants, Mac OS X, Solaris, AIX, HP-UX, as well as on other *nix flavours. It also has a proof of concept port for Microsoft Windows.

''The following is community-contributed documentation on Nginx configuration. Amendments and additions are welcome.''

== Nginx configuration ==

=== PHP-FPM ===

Nginx is usually configured to interface with PHP via [http://php.net/manual/en/install.fpm.php php-fpm]. This is both fast and robust.

PHP-FPM's default behaviour for pools is usually to restrict the execution of scripts to a specific extension, i.e. .php. You should ensure that this behaviour is configured within your particular package/distribution, e.g. for debian,

'''/etc/php5/fpm/pool.d/www.conf'''
security.limit_extensions = .php

=== Nginx ===

Add the following 'slash arguments' compatible 'location' block to your vhosts 'server' in your nginx configuration (further explanation at '[[Using slash arguments]]').

'''nginx.conf location:'''
<pre>
location ~ [^/]\.php(/|$) {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_index index.php;
fastcgi_pass 127.0.0.1:9000 (or your php-fpm socket);
include fastcgi_params;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
</pre>

If the above does not work try the following:
Note: This was for CentOS 7.6 (1804), MariaDB 10.3, Nginx 1.15 and PHP 7.3.5
<pre>
location ~ ^(.+\.php)(.*)$ {
root /usr/share/nginx/html/moodle/;
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_index index.php;
fastcgi_pass 127.0.0.1:9000;
include /etc/nginx/mime.types;
include fastcgi_params;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
</pre>

If you find that this does not work (scripts, styles, and images not loading) '''and''' that there are <code>open() "..." failed (20: Not a directory)</code> lines appearing in your logs: Check whether there are any directives related to static content '''before''' this block and try moving them '''after''' this block.

Another potential pitfall is the use of '''try_files'''. Many guides recommend configurations like <pre>try_files $fastcgi_script_name =404;</pre>. But if try_files is used, nginx deletes the content of the '''$fastcgi_path_info''' variable (this is [https://trac.nginx.org/nginx/ticket/321 intended behavior]). This causes '''PATH_INFO''' to also be empty, so slash arguments don't work.
An alternative is the use of <pre>if(!-f $document_root$fastcgi_script_name) {return 404;}</pre> [https://www.nginx.com/resources/wiki/start/topics/examples/phpfcgi/#connecting-nginx-to-php-fpm as recommended] by the nginx documentation, although the nginx documentation also recommends [https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/ not using if].

==== Error pages ====

<pre>
# This passes 404 pages to Moodle so they can be themed
error_page 404 /error/index.php; error_page 403 =404 /error/index.php;
</pre>

==== Hiding internal files ====

<pre>
# Hide all dot files but allow "Well-Known URIs" as per RFC 5785
location ~ /\.(?!well-known).* {
return 404;
}

# This should be after the php fpm rule and very close to the last nginx ruleset.
# Don't allow direct access to various internal files. See MDL-69333
location ~ (/vendor/|/node_modules/|composer\.json|/readme|/README|readme\.txt|/upgrade\.txt|db/install\.xml|/fixtures/|/behat/|phpunit\.xml|\.lock|environment\.xml) {
deny all;
return 404;
}
</pre>

===== XSendfile aka X-Accel-Redirect =====

Setting Moodle and Nginx to use XSendfile functionality is a big win as it frees PHP from delivering files allowing Nginx to do what it does best, i.e. deliver files.

Enable xsendfile for Nginx in Moodles config.php, this is documented in the config-dist.php, a minimal configuration look like this,
<pre>
$CFG->xsendfile = 'X-Accel-Redirect';
$CFG->xsendfilealiases = array(
'/dataroot/' => $CFG->dataroot
);
</pre>
Accompany this with a matching 'location' block in your nginx server configuration.
<pre>
location /dataroot/ {
internal;
alias <full_moodledata_path>; # ensure the path ends with /
}
</pre>
The definition of 'internal' here is '''critical''' as it prevents client access to your dataroot.

== See also ==

* Real <tt>PATH_INFO</tt> support:
** https://moodle.org/mod/forum/discuss.php?d=278916
** https://moodle.org/mod/forum/discuss.php?d=307388
* '''[Deprecated]''' Internal rewriting to the HTTP GET <tt>file</tt> parameter:
** https://moodle.org/mod/forum/discuss.php?d=83445

[[Category:Installation]]

[[es:Nginx]]
[[pt-br:Nginx]]

Nginx

2021-05-24T09:26:27Z

Brendanheywood: Add error pages and hiding internal files

{{Installing Moodle}}[[Nginx]] [engine x] is an HTTP and reverse proxy server, as well as a mail proxy server, written by Igor Sysoev. The nginx project started with a strong focus on high concurrency, high performance and low memory usage. It is licensed under the 2-clause BSD-like license and it runs on Linux, BSD variants, Mac OS X, Solaris, AIX, HP-UX, as well as on other *nix flavours. It also has a proof of concept port for Microsoft Windows.

''The following is community-contributed documentation on Nginx configuration. Amendments and additions are welcome.''

== Nginx configuration ==

=== PHP-FPM ===

Nginx is usually configured to interface with PHP via [http://php.net/manual/en/install.fpm.php php-fpm]. This is both fast and robust.

PHP-FPM's default behaviour for pools is usually to restrict the execution of scripts to a specific extension, i.e. .php. You should ensure that this behaviour is configured within your particular package/distribution, e.g. for debian,

'''/etc/php5/fpm/pool.d/www.conf'''
security.limit_extensions = .php

=== Nginx ===

Add the following 'slash arguments' compatible 'location' block to your vhosts 'server' in your nginx configuration (further explanation at '[[Using slash arguments]]').

'''nginx.conf location:'''
<pre>
location ~ [^/]\.php(/|$) {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_index index.php;
fastcgi_pass 127.0.0.1:9000 (or your php-fpm socket);
include fastcgi_params;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
</pre>

If the above does not work try the following:
Note: This was for CentOS 7.6 (1804), MariaDB 10.3, Nginx 1.15 and PHP 7.3.5
<pre>
location ~ ^(.+\.php)(.*)$ {
root /usr/share/nginx/html/moodle/;
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_index index.php;
fastcgi_pass 127.0.0.1:9000;
include /etc/nginx/mime.types;
include fastcgi_params;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
</pre>

If you find that this does not work (scripts, styles, and images not loading) '''and''' that there are <code>open() "..." failed (20: Not a directory)</code> lines appearing in your logs: Check whether there are any directives related to static content '''before''' this block and try moving them '''after''' this block.

Another potential pitfall is the use of '''try_files'''. Many guides recommend configurations like <pre>try_files $fastcgi_script_name =404;</pre>. But if try_files is used, nginx deletes the content of the '''$fastcgi_path_info''' variable (this is [https://trac.nginx.org/nginx/ticket/321 intended behavior]). This causes '''PATH_INFO''' to also be empty, so slash arguments don't work.
An alternative is the use of <pre>if(!-f $document_root$fastcgi_script_name) {return 404;}</pre> [https://www.nginx.com/resources/wiki/start/topics/examples/phpfcgi/#connecting-nginx-to-php-fpm as recommended] by the nginx documentation, although the nginx documentation also recommends [https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/ not using if].

=== Error pages ===

<pre>
# This passes 404 pages to Moodle so they can be themed
error_page 404 /error/index.php; error_page 403 =404 /error/index.php;
</pre>

=== Hiding internal files ===

<pre>
# Hide all dot files but allow "Well-Known URIs" as per RFC 5785
location ~ /\.(?!well-known).* {
return 404;
}

# This should be after the php fpm rule and very close to the last nginx ruleset.
# Don't allow direct access to various internal files. See MDL-69333
location ~ (/vendor/|/node_modules/|composer\.json|/readme|/README|readme\.txt|/upgrade\.txt|db/install\.xml|/fixtures/|/behat/|phpunit\.xml|\.lock|environment\.xml) {
deny all;
return 404;
}
</pre>

===== XSendfile aka X-Accel-Redirect =====

Setting Moodle and Nginx to use XSendfile functionality is a big win as it frees PHP from delivering files allowing Nginx to do what it does best, i.e. deliver files.

Enable xsendfile for Nginx in Moodles config.php, this is documented in the config-dist.php, a minimal configuration look like this,
<pre>
$CFG->xsendfile = 'X-Accel-Redirect';
$CFG->xsendfilealiases = array(
'/dataroot/' => $CFG->dataroot
);
</pre>
Accompany this with a matching 'location' block in your nginx server configuration.
<pre>
location /dataroot/ {
internal;
alias <full_moodledata_path>; # ensure the path ends with /
}
</pre>
The definition of 'internal' here is '''critical''' as it prevents client access to your dataroot.

== See also ==

* Real <tt>PATH_INFO</tt> support:
** https://moodle.org/mod/forum/discuss.php?d=278916
** https://moodle.org/mod/forum/discuss.php?d=307388
* '''[Deprecated]''' Internal rewriting to the HTTP GET <tt>file</tt> parameter:
** https://moodle.org/mod/forum/discuss.php?d=83445

[[Category:Installation]]

[[es:Nginx]]
[[pt-br:Nginx]]

Server cluster

2021-03-15T22:53:31Z

Brendanheywood: /* $CFG->backuptempdir */

This page is going to describe some basic information related to server clustering...

==Requirements==

* database server - ACID compliant, for example PostgreSQL and MariaDB
* main server that is able to share dataroot - locking support recommended, for example NFS
* load balancer - for example Nginx
* cluster nodes - web servers
* Redis (or Memcached) server for shared MUC caches

Note: this guide is not intended for Windows OS or any other Microsoft technologies.

==Initial installation==

# Perform standard CLI installation on the main server using shared database and dataroot directory.
# Setup web servers on cluster nodes - use local dirroot and shared database and dataroot.
# Configure load balancing.

==Related config.php settings==

===$CFG->wwwroot===
It must be the same on all nodes, it must be the public facing URL. It cannot be dynamic.

===$CFG->sslproxy===
Enable if you have https:// wwwroot but the SSL is done by load-balancer instead of web server.

Please note that it is not compatible with $CFG->loginhttps. This is because in order for loginhttps to work, we need to know the original request, and whether it was http or https. This allows us to only provide the login form over ssl. The original request is lost when made through a "reverse" proxy / load balancer, so we cannot determine what protocol the request was made in. So we can't provide most of moodle over http and the login page over https.

Enable ''Secure cookies only'' to make your site really secure, without it cookie stealing is still trivial.

===$CFG->reverseproxy===
Enable if your nodes are accessed via different URL.

Please note that it is not compatible with $CFG->loginhttps. This is because in order for loginhttps to work, we need to know the original request, and whether it was http or https. This allows us to only provide the login form over ssl. The original request is lost when made through a "reverse" proxy / load balancer, so we cannot determine what protocol the request was made in. So we can't provide most of moodle over http and the login page over https.

===$CFG->dirroot===
It is strongly recommended that $CFG->dirroot (which is automatically set via realpath(config.php)) contains the same path on all nodes. It does not need to point to the same shared directory though. The reason is that some some low level code may use the dirroot value for cache invalidation.

The simplest solution is to have the same directory structure on each cluster node and synchronise these during each upgrade.

The dirroot should be always read only for apache process because otherwise built in plugin installation and uninstallation would get the nodes out of sync.

===$CFG->dataroot===

This '''MUST''' be a shared directory where each cluster node is accessing the files directly. It must be very reliable, administrators cannot manipulate files directly.

Locking support is not required, if any code tries to use file locks in dataroot outside of cachedir or muc directory it is a bug.

===$CFG->alternative_file_system_class===

By default all uploaded content files are de-duplicated are stored inside [$CFG->dataroot]/filedir. But you can replace this is an alternative file store, like a cloud store such as AWS S3.

<code php>
$CFG->alternative_file_system_class = '\tool_objectfs\s3_file_system';
</code>

https://github.com/catalyst/moodle-tool_objectfs/

NOTE: Even if you use an alternate filesystem you '''MUST''' still have a shared $CFG->dataroot.

===$CFG->tempdir===

This directory '''MUST''' be shared by all cluster nodes. Locking is required.

===$CFG->cachedir===

This directory '''MUST''' be shared by all cluster nodes. Locking is required.

===$CFG->localcachedir===

The difference from $CFG->cachedir is that the directory does not have to be shared by all cluster nodes, the file contents do not change. Use local fast filesystem on each cluster node.

The nature of this path is very slow moving files that stay for a long time and are written once and never overwritten.

===$CFG->localrequestdir===

By default this is created inside /tmp or whatever sys_get_temp_dir() returns and is generally already local disk and not shared with other nodes. This directory holds temporary folders and files which only exist for the duration of a single http request. If you do change this use local fast filesystem on each cluster node.

===$CFG->backuptempdir===

Server clusters MUST use shared filesystem for backuptempdir! This directory gets very large and fast bursts of IO but files do not generally live here for any length of time. They are write heavy and do not have much contention.

==Performance recommendations==

#Use OPcache extension on all cluster nodes.
#Set $CFG->localcachedir to fast local filesystem on each node.
#Use one big central memcached server for all shared caches that support it.
#Use local memcached instances on cluster nodes for local caches that support it.
#Store user sessions in one shared server eg Redis. (See [[Session_handling]] for details)
#Use fast local directory for dirroot on each cluster node.
#Use dynamic cluster node management.
#Use transparent proxy servers.

==Upgrade procedure==

#Disable load balancer.
#Upgrade dirroot files on master server.
#Perform CLI upgrade.
#Manually reset all caches in cluster nodes - restart web server, delete localcachedir and temp directories, restart memcached, etc. Or delete all cluster nodes and create nodes from a new template.
#Enable load balancer.

==Step by step guide for server clustering in Moodle 2.6==
From hardware and performance forum thread [https://moodle.org/mod/forum/discuss.php?d=251547 https://moodle.org/mod/forum/discuss.php?d=251547]

* 1 Determine your specific need for caches. This involves the concepts of shared cache or local cache, disk based cache or server based cache or protocol specific cache like Memcached or MongoDB.
** 1.1 If you have a slow shared disk, you might benefit from a local disk cache.
** 1.2 If you have only a few users on your Moodle site, you might not want to set up a Memcached service, even if the acceleration that Memcached provides, is very significant for the user experience.
** 1.3 If you want to do anything in your power for accelerating the site, you might consider MongoDB.
* 2 Configure the caches, test them and verify them. There is room for improvement in the examples for cache configuration. This is probably the most difficult step.
* 3 Install the cache support on server level. This may involve installing php modules or config for php modules.
* 4 Create a cache instance in MUC here: example.com/cache/admin.php?action=addstore&plugin=memcached
** 4.1 Give the cache instance some arbitrary name.
** 4.2 All other fields have a question mark that can be clicked on for excellent help that tells you what to fill in, and the syntax (very important).
** 4.3 The result should be a Configured Store Instance, with the name of your choice.
* 5 The final step is to deploy the created cache instances by Editing Mappings for e.g. Language string cache in the list of Known cache definitions.
** 5.1 While experimenting with this, I have found it a life saver to open a separate browser window, where the default setting is selected, so I just need to click on the Save button to revert the setting, just in case I lose contact with the site.
** 5.2 Select the name of your configured store instance from the dropdown list and click on the Save button.
** 5.3 Test the new cache setting. If you lose contact with the site or it behaves weirdly, try using the trick in step 1. In case of emergency you might remove the cache config file (muc/config.php) in the folder pointed to by $CFG->dataroot . It seems that Moodle writes a new default config file if it is missing.

==See also==
*[[Performance recommendations]]
*[[Caching]]
*[[:dev:Server clustering improvements proposal]]
*Hardware and performance forum thread [https://moodle.org/mod/forum/discuss.php?d=251547https://moodle.org/mod/forum/discuss.php?d=251547]
*How to Cluster Moodle on Multiple Servers for High Availability and Scalability [http://www.severalnines.com/blog/clustering-moodle-multiple-servers-high-availability-scalability]
* PHP session cache in a cluster
** https://www.digitalocean.com/community/tutorials/how-to-set-up-a-redis-server-as-a-session-handler-for-php-on-ubuntu-14-04
** https://inchoo.net/magento/programming-magento/session-storage-php

Server cluster

2021-02-08T22:58:52Z

Brendanheywood: /* $CFG->alternative_file_system_class */

This page is going to describe some basic information related to server clustering...

==Requirements==

* database server - ACID compliant, for example PostgreSQL and MariaDB
* main server that is able to share dataroot - locking support recommended, for example NFS
* load balancer - for example Nginx
* cluster nodes - web servers
* Redis (or Memcached) server for shared MUC caches

Note: this guide is not intended for Windows OS or any other Microsoft technologies.

==Initial installation==

# Perform standard CLI installation on the main server using shared database and dataroot directory.
# Setup web servers on cluster nodes - use local dirroot and shared database and dataroot.
# Configure load balancing.

==Related config.php settings==

===$CFG->wwwroot===
It must be the same on all nodes, it must be the public facing URL. It cannot be dynamic.

===$CFG->sslproxy===
Enable if you have https:// wwwroot but the SSL is done by load-balancer instead of web server.

Please note that it is not compatible with $CFG->loginhttps. This is because in order for loginhttps to work, we need to know the original request, and whether it was http or https. This allows us to only provide the login form over ssl. The original request is lost when made through a "reverse" proxy / load balancer, so we cannot determine what protocol the request was made in. So we can't provide most of moodle over http and the login page over https.

Enable ''Secure cookies only'' to make your site really secure, without it cookie stealing is still trivial.

===$CFG->reverseproxy===
Enable if your nodes are accessed via different URL.

Please note that it is not compatible with $CFG->loginhttps. This is because in order for loginhttps to work, we need to know the original request, and whether it was http or https. This allows us to only provide the login form over ssl. The original request is lost when made through a "reverse" proxy / load balancer, so we cannot determine what protocol the request was made in. So we can't provide most of moodle over http and the login page over https.

===$CFG->dirroot===
It is strongly recommended that $CFG->dirroot (which is automatically set via realpath(config.php)) contains the same path on all nodes. It does not need to point to the same shared directory though. The reason is that some some low level code may use the dirroot value for cache invalidation.

The simplest solution is to have the same directory structure on each cluster node and synchronise these during each upgrade.

The dirroot should be always read only for apache process because otherwise built in plugin installation and uninstallation would get the nodes out of sync.

===$CFG->dataroot===

This '''MUST''' be a shared directory where each cluster node is accessing the files directly. It must be very reliable, administrators cannot manipulate files directly.

Locking support is not required, if any code tries to use file locks in dataroot outside of cachedir or muc directory it is a bug.

===$CFG->alternative_file_system_class===

By default all uploaded content files are de-duplicated are stored inside [$CFG->dataroot]/filedir. But you can replace this is an alternative file store, like a cloud store such as AWS S3.

<code php>
$CFG->alternative_file_system_class = '\tool_objectfs\s3_file_system';
</code>

https://github.com/catalyst/moodle-tool_objectfs/

NOTE: Even if you use an alternate filesystem you '''MUST''' still have a shared $CFG->dataroot.

===$CFG->tempdir===

This directory '''MUST''' be shared by all cluster nodes. Locking is required.

===$CFG->cachedir===

This directory '''MUST''' be shared by all cluster nodes. Locking is required.

===$CFG->localcachedir===

The difference from $CFG->cachedir is that the directory does not have to be shared by all cluster nodes, the file contents do not change. Use local fast filesystem on each cluster node.

The nature of this path is very slow moving files that stay for a long time and are written once and never overwritten.

===$CFG->localrequestdir===

By default this is created inside /tmp or whatever sys_get_temp_dir() returns and is generally already local disk and not shared with other nodes. This directory holds temporary folders and files which only exist for the duration of a single http request. If you do change this use local fast filesystem on each cluster node.

==Performance recommendations==

#Use OPcache extension on all cluster nodes.
#Set $CFG->localcachedir to fast local filesystem on each node.
#Use one big central memcached server for all shared caches that support it.
#Use local memcached instances on cluster nodes for local caches that support it.
#Store user sessions in one shared server eg Redis. (See [[Session_handling]] for details)
#Use fast local directory for dirroot on each cluster node.
#Use dynamic cluster node management.
#Use transparent proxy servers.

==Upgrade procedure==

#Disable load balancer.
#Upgrade dirroot files on master server.
#Perform CLI upgrade.
#Manually reset all caches in cluster nodes - restart web server, delete localcachedir and temp directories, restart memcached, etc. Or delete all cluster nodes and create nodes from a new template.
#Enable load balancer.

==Step by step guide for server clustering in Moodle 2.6==
From hardware and performance forum thread [https://moodle.org/mod/forum/discuss.php?d=251547 https://moodle.org/mod/forum/discuss.php?d=251547]

* 1 Determine your specific need for caches. This involves the concepts of shared cache or local cache, disk based cache or server based cache or protocol specific cache like Memcached or MongoDB.
** 1.1 If you have a slow shared disk, you might benefit from a local disk cache.
** 1.2 If you have only a few users on your Moodle site, you might not want to set up a Memcached service, even if the acceleration that Memcached provides, is very significant for the user experience.
** 1.3 If you want to do anything in your power for accelerating the site, you might consider MongoDB.
* 2 Configure the caches, test them and verify them. There is room for improvement in the examples for cache configuration. This is probably the most difficult step.
* 3 Install the cache support on server level. This may involve installing php modules or config for php modules.
* 4 Create a cache instance in MUC here: example.com/cache/admin.php?action=addstore&plugin=memcached
** 4.1 Give the cache instance some arbitrary name.
** 4.2 All other fields have a question mark that can be clicked on for excellent help that tells you what to fill in, and the syntax (very important).
** 4.3 The result should be a Configured Store Instance, with the name of your choice.
* 5 The final step is to deploy the created cache instances by Editing Mappings for e.g. Language string cache in the list of Known cache definitions.
** 5.1 While experimenting with this, I have found it a life saver to open a separate browser window, where the default setting is selected, so I just need to click on the Save button to revert the setting, just in case I lose contact with the site.
** 5.2 Select the name of your configured store instance from the dropdown list and click on the Save button.
** 5.3 Test the new cache setting. If you lose contact with the site or it behaves weirdly, try using the trick in step 1. In case of emergency you might remove the cache config file (muc/config.php) in the folder pointed to by $CFG->dataroot . It seems that Moodle writes a new default config file if it is missing.

==See also==
*[[Performance recommendations]]
*[[Caching]]
*[[:dev:Server clustering improvements proposal]]
*Hardware and performance forum thread [https://moodle.org/mod/forum/discuss.php?d=251547https://moodle.org/mod/forum/discuss.php?d=251547]
*How to Cluster Moodle on Multiple Servers for High Availability and Scalability [http://www.severalnines.com/blog/clustering-moodle-multiple-servers-high-availability-scalability]
* PHP session cache in a cluster
** https://www.digitalocean.com/community/tutorials/how-to-set-up-a-redis-server-as-a-session-handler-for-php-on-ubuntu-14-04
** https://inchoo.net/magento/programming-magento/session-storage-php

Server cluster

2021-02-08T22:46:26Z

Brendanheywood: /* $CFG->dataroot */

This page is going to describe some basic information related to server clustering...

==Requirements==

* database server - ACID compliant, for example PostgreSQL and MariaDB
* main server that is able to share dataroot - locking support recommended, for example NFS
* load balancer - for example Nginx
* cluster nodes - web servers
* Redis (or Memcached) server for shared MUC caches

Note: this guide is not intended for Windows OS or any other Microsoft technologies.

==Initial installation==

# Perform standard CLI installation on the main server using shared database and dataroot directory.
# Setup web servers on cluster nodes - use local dirroot and shared database and dataroot.
# Configure load balancing.

==Related config.php settings==

===$CFG->wwwroot===
It must be the same on all nodes, it must be the public facing URL. It cannot be dynamic.

===$CFG->sslproxy===
Enable if you have https:// wwwroot but the SSL is done by load-balancer instead of web server.

Please note that it is not compatible with $CFG->loginhttps. This is because in order for loginhttps to work, we need to know the original request, and whether it was http or https. This allows us to only provide the login form over ssl. The original request is lost when made through a "reverse" proxy / load balancer, so we cannot determine what protocol the request was made in. So we can't provide most of moodle over http and the login page over https.

Enable ''Secure cookies only'' to make your site really secure, without it cookie stealing is still trivial.

===$CFG->reverseproxy===
Enable if your nodes are accessed via different URL.

Please note that it is not compatible with $CFG->loginhttps. This is because in order for loginhttps to work, we need to know the original request, and whether it was http or https. This allows us to only provide the login form over ssl. The original request is lost when made through a "reverse" proxy / load balancer, so we cannot determine what protocol the request was made in. So we can't provide most of moodle over http and the login page over https.

===$CFG->dirroot===
It is strongly recommended that $CFG->dirroot (which is automatically set via realpath(config.php)) contains the same path on all nodes. It does not need to point to the same shared directory though. The reason is that some some low level code may use the dirroot value for cache invalidation.

The simplest solution is to have the same directory structure on each cluster node and synchronise these during each upgrade.

The dirroot should be always read only for apache process because otherwise built in plugin installation and uninstallation would get the nodes out of sync.

===$CFG->dataroot===

This '''MUST''' be a shared directory where each cluster node is accessing the files directly. It must be very reliable, administrators cannot manipulate files directly.

Locking support is not required, if any code tries to use file locks in dataroot outside of cachedir or muc directory it is a bug.

===$CFG->alternative_file_system_class===

By default all uploaded content files are de-duplicated are stored inside [$CFG->dataroot]/filedir. But you can replace this is an alternative file store, like a cloud store such as AWS S3.

<code php>
$CFG->alternative_file_system_class = '\tool_objectfs\s3_file_system';
</code>

https://github.com/catalyst/moodle-tool_objectfs/

NOTE: Even if you use an alternate filesystem you MUST still have a shared $CFG->dataroot.

===$CFG->tempdir===

This directory '''MUST''' be shared by all cluster nodes. Locking is required.

===$CFG->cachedir===

This directory '''MUST''' be shared by all cluster nodes. Locking is required.

===$CFG->localcachedir===

The difference from $CFG->cachedir is that the directory does not have to be shared by all cluster nodes, the file contents do not change. Use local fast filesystem on each cluster node.

The nature of this path is very slow moving files that stay for a long time and are written once and never overwritten.

===$CFG->localrequestdir===

By default this is created inside /tmp or whatever sys_get_temp_dir() returns and is generally already local disk and not shared with other nodes. This directory holds temporary folders and files which only exist for the duration of a single http request. If you do change this use local fast filesystem on each cluster node.

==Performance recommendations==

#Use OPcache extension on all cluster nodes.
#Set $CFG->localcachedir to fast local filesystem on each node.
#Use one big central memcached server for all shared caches that support it.
#Use local memcached instances on cluster nodes for local caches that support it.
#Store user sessions in one shared server eg Redis. (See [[Session_handling]] for details)
#Use fast local directory for dirroot on each cluster node.
#Use dynamic cluster node management.
#Use transparent proxy servers.

==Upgrade procedure==

#Disable load balancer.
#Upgrade dirroot files on master server.
#Perform CLI upgrade.
#Manually reset all caches in cluster nodes - restart web server, delete localcachedir and temp directories, restart memcached, etc. Or delete all cluster nodes and create nodes from a new template.
#Enable load balancer.

==Step by step guide for server clustering in Moodle 2.6==
From hardware and performance forum thread [https://moodle.org/mod/forum/discuss.php?d=251547 https://moodle.org/mod/forum/discuss.php?d=251547]

* 1 Determine your specific need for caches. This involves the concepts of shared cache or local cache, disk based cache or server based cache or protocol specific cache like Memcached or MongoDB.
** 1.1 If you have a slow shared disk, you might benefit from a local disk cache.
** 1.2 If you have only a few users on your Moodle site, you might not want to set up a Memcached service, even if the acceleration that Memcached provides, is very significant for the user experience.
** 1.3 If you want to do anything in your power for accelerating the site, you might consider MongoDB.
* 2 Configure the caches, test them and verify them. There is room for improvement in the examples for cache configuration. This is probably the most difficult step.
* 3 Install the cache support on server level. This may involve installing php modules or config for php modules.
* 4 Create a cache instance in MUC here: example.com/cache/admin.php?action=addstore&plugin=memcached
** 4.1 Give the cache instance some arbitrary name.
** 4.2 All other fields have a question mark that can be clicked on for excellent help that tells you what to fill in, and the syntax (very important).
** 4.3 The result should be a Configured Store Instance, with the name of your choice.
* 5 The final step is to deploy the created cache instances by Editing Mappings for e.g. Language string cache in the list of Known cache definitions.
** 5.1 While experimenting with this, I have found it a life saver to open a separate browser window, where the default setting is selected, so I just need to click on the Save button to revert the setting, just in case I lose contact with the site.
** 5.2 Select the name of your configured store instance from the dropdown list and click on the Save button.
** 5.3 Test the new cache setting. If you lose contact with the site or it behaves weirdly, try using the trick in step 1. In case of emergency you might remove the cache config file (muc/config.php) in the folder pointed to by $CFG->dataroot . It seems that Moodle writes a new default config file if it is missing.

==See also==
*[[Performance recommendations]]
*[[Caching]]
*[[:dev:Server clustering improvements proposal]]
*Hardware and performance forum thread [https://moodle.org/mod/forum/discuss.php?d=251547https://moodle.org/mod/forum/discuss.php?d=251547]
*How to Cluster Moodle on Multiple Servers for High Availability and Scalability [http://www.severalnines.com/blog/clustering-moodle-multiple-servers-high-availability-scalability]
* PHP session cache in a cluster
** https://www.digitalocean.com/community/tutorials/how-to-set-up-a-redis-server-as-a-session-handler-for-php-on-ubuntu-14-04
** https://inchoo.net/magento/programming-magento/session-storage-php

Server cluster

2021-02-08T22:46:11Z

Brendanheywood: $CFG->alternative_file_system_class

This page is going to describe some basic information related to server clustering...

==Requirements==

* database server - ACID compliant, for example PostgreSQL and MariaDB
* main server that is able to share dataroot - locking support recommended, for example NFS
* load balancer - for example Nginx
* cluster nodes - web servers
* Redis (or Memcached) server for shared MUC caches

Note: this guide is not intended for Windows OS or any other Microsoft technologies.

==Initial installation==

# Perform standard CLI installation on the main server using shared database and dataroot directory.
# Setup web servers on cluster nodes - use local dirroot and shared database and dataroot.
# Configure load balancing.

==Related config.php settings==

===$CFG->wwwroot===
It must be the same on all nodes, it must be the public facing URL. It cannot be dynamic.

===$CFG->sslproxy===
Enable if you have https:// wwwroot but the SSL is done by load-balancer instead of web server.

Please note that it is not compatible with $CFG->loginhttps. This is because in order for loginhttps to work, we need to know the original request, and whether it was http or https. This allows us to only provide the login form over ssl. The original request is lost when made through a "reverse" proxy / load balancer, so we cannot determine what protocol the request was made in. So we can't provide most of moodle over http and the login page over https.

Enable ''Secure cookies only'' to make your site really secure, without it cookie stealing is still trivial.

===$CFG->reverseproxy===
Enable if your nodes are accessed via different URL.

Please note that it is not compatible with $CFG->loginhttps. This is because in order for loginhttps to work, we need to know the original request, and whether it was http or https. This allows us to only provide the login form over ssl. The original request is lost when made through a "reverse" proxy / load balancer, so we cannot determine what protocol the request was made in. So we can't provide most of moodle over http and the login page over https.

===$CFG->dirroot===
It is strongly recommended that $CFG->dirroot (which is automatically set via realpath(config.php)) contains the same path on all nodes. It does not need to point to the same shared directory though. The reason is that some some low level code may use the dirroot value for cache invalidation.

The simplest solution is to have the same directory structure on each cluster node and synchronise these during each upgrade.

The dirroot should be always read only for apache process because otherwise built in plugin installation and uninstallation would get the nodes out of sync.

===$CFG->dataroot===

This '''MUST''' be a shared directory where each cluster node is accessing the files directly. It must be very reliable, administrators cannot manipulate files directly.

Locking support is not required, if any code tries to use file locks in dataroot outside of cachedir or muc directory it is a bug.

===$CFG->alternative_file_system_class===

By default all uploaded content files are de-duplicated are stored inside [$CFG->dataroot]/filedir. But you can replace this is an alternative file store, like a cloud store such as AWS S3.

<code php>
$CFG->alternative_file_system_class = '\tool_objectfs\s3_file_system';
</code>

https://github.com/catalyst/moodle-tool_objectfs/

NOTE: Even if you use an alternate filesystem you MUST still have a shared $CFG->dataroot.

===$CFG->tempdir===

This directory '''MUST''' be shared by all cluster nodes. Locking is required.

===$CFG->cachedir===

This directory '''MUST''' be shared by all cluster nodes. Locking is required.

===$CFG->localcachedir===

The difference from $CFG->cachedir is that the directory does not have to be shared by all cluster nodes, the file contents do not change. Use local fast filesystem on each cluster node.

The nature of this path is very slow moving files that stay for a long time and are written once and never overwritten.

===$CFG->localrequestdir===

By default this is created inside /tmp or whatever sys_get_temp_dir() returns and is generally already local disk and not shared with other nodes. This directory holds temporary folders and files which only exist for the duration of a single http request. If you do change this use local fast filesystem on each cluster node.

==Performance recommendations==

#Use OPcache extension on all cluster nodes.
#Set $CFG->localcachedir to fast local filesystem on each node.
#Use one big central memcached server for all shared caches that support it.
#Use local memcached instances on cluster nodes for local caches that support it.
#Store user sessions in one shared server eg Redis. (See [[Session_handling]] for details)
#Use fast local directory for dirroot on each cluster node.
#Use dynamic cluster node management.
#Use transparent proxy servers.

==Upgrade procedure==

#Disable load balancer.
#Upgrade dirroot files on master server.
#Perform CLI upgrade.
#Manually reset all caches in cluster nodes - restart web server, delete localcachedir and temp directories, restart memcached, etc. Or delete all cluster nodes and create nodes from a new template.
#Enable load balancer.

==Step by step guide for server clustering in Moodle 2.6==
From hardware and performance forum thread [https://moodle.org/mod/forum/discuss.php?d=251547 https://moodle.org/mod/forum/discuss.php?d=251547]

* 1 Determine your specific need for caches. This involves the concepts of shared cache or local cache, disk based cache or server based cache or protocol specific cache like Memcached or MongoDB.
** 1.1 If you have a slow shared disk, you might benefit from a local disk cache.
** 1.2 If you have only a few users on your Moodle site, you might not want to set up a Memcached service, even if the acceleration that Memcached provides, is very significant for the user experience.
** 1.3 If you want to do anything in your power for accelerating the site, you might consider MongoDB.
* 2 Configure the caches, test them and verify them. There is room for improvement in the examples for cache configuration. This is probably the most difficult step.
* 3 Install the cache support on server level. This may involve installing php modules or config for php modules.
* 4 Create a cache instance in MUC here: example.com/cache/admin.php?action=addstore&plugin=memcached
** 4.1 Give the cache instance some arbitrary name.
** 4.2 All other fields have a question mark that can be clicked on for excellent help that tells you what to fill in, and the syntax (very important).
** 4.3 The result should be a Configured Store Instance, with the name of your choice.
* 5 The final step is to deploy the created cache instances by Editing Mappings for e.g. Language string cache in the list of Known cache definitions.
** 5.1 While experimenting with this, I have found it a life saver to open a separate browser window, where the default setting is selected, so I just need to click on the Save button to revert the setting, just in case I lose contact with the site.
** 5.2 Select the name of your configured store instance from the dropdown list and click on the Save button.
** 5.3 Test the new cache setting. If you lose contact with the site or it behaves weirdly, try using the trick in step 1. In case of emergency you might remove the cache config file (muc/config.php) in the folder pointed to by $CFG->dataroot . It seems that Moodle writes a new default config file if it is missing.

==See also==
*[[Performance recommendations]]
*[[Caching]]
*[[:dev:Server clustering improvements proposal]]
*Hardware and performance forum thread [https://moodle.org/mod/forum/discuss.php?d=251547https://moodle.org/mod/forum/discuss.php?d=251547]
*How to Cluster Moodle on Multiple Servers for High Availability and Scalability [http://www.severalnines.com/blog/clustering-moodle-multiple-servers-high-availability-scalability]
* PHP session cache in a cluster
** https://www.digitalocean.com/community/tutorials/how-to-set-up-a-redis-server-as-a-session-handler-for-php-on-ubuntu-14-04
** https://inchoo.net/magento/programming-magento/session-storage-php

Server cluster

2021-02-08T22:22:45Z

Brendanheywood: /* Performance recommendations */

This page is going to describe some basic information related to server clustering...

==Requirements==

* database server - ACID compliant, for example PostgreSQL and MariaDB
* main server that is able to share dataroot - locking support recommended, for example NFS
* load balancer - for example Nginx
* cluster nodes - web servers
* Redis (or Memcached) server for shared MUC caches

Note: this guide is not intended for Windows OS or any other Microsoft technologies.

==Initial installation==

# Perform standard CLI installation on the main server using shared database and dataroot directory.
# Setup web servers on cluster nodes - use local dirroot and shared database and dataroot.
# Configure load balancing.

==Related config.php settings==

===$CFG->wwwroot===
It must be the same on all nodes, it must be the public facing URL. It cannot be dynamic.

===$CFG->sslproxy===
Enable if you have https:// wwwroot but the SSL is done by load-balancer instead of web server.

Please note that it is not compatible with $CFG->loginhttps. This is because in order for loginhttps to work, we need to know the original request, and whether it was http or https. This allows us to only provide the login form over ssl. The original request is lost when made through a "reverse" proxy / load balancer, so we cannot determine what protocol the request was made in. So we can't provide most of moodle over http and the login page over https.

Enable ''Secure cookies only'' to make your site really secure, without it cookie stealing is still trivial.

===$CFG->reverseproxy===
Enable if your nodes are accessed via different URL.

Please note that it is not compatible with $CFG->loginhttps. This is because in order for loginhttps to work, we need to know the original request, and whether it was http or https. This allows us to only provide the login form over ssl. The original request is lost when made through a "reverse" proxy / load balancer, so we cannot determine what protocol the request was made in. So we can't provide most of moodle over http and the login page over https.

===$CFG->dirroot===
It is strongly recommended that $CFG->dirroot (which is automatically set via realpath(config.php)) contains the same path on all nodes. It does not need to point to the same shared directory though. The reason is that some some low level code may use the dirroot value for cache invalidation.

The simplest solution is to have the same directory structure on each cluster node and synchronise these during each upgrade.

The dirroot should be always read only for apache process because otherwise built in plugin installation and uninstallation would get the nodes out of sync.

===$CFG->dataroot===

This '''MUST''' be a shared directory where each cluster node is accessing the files directly. It must be very reliable, administrators cannot manipulate files directly.

Locking support is not required, if any code tries to use file locks in dataroot outside of cachedir or muc directory it is a bug.

===$CFG->tempdir===

This directory '''MUST''' be shared by all cluster nodes. Locking is required.

===$CFG->cachedir===

This directory '''MUST''' be shared by all cluster nodes. Locking is required.

===$CFG->localcachedir===

The difference from $CFG->cachedir is that the directory does not have to be shared by all cluster nodes, the file contents do not change. Use local fast filesystem on each cluster node.

The nature of this path is very slow moving files that stay for a long time and are written once and never overwritten.

===$CFG->localrequestdir===

By default this is created inside /tmp or whatever sys_get_temp_dir() returns and is generally already local disk and not shared with other nodes. This directory holds temporary folders and files which only exist for the duration of a single http request. If you do change this use local fast filesystem on each cluster node.

==Performance recommendations==

#Use OPcache extension on all cluster nodes.
#Set $CFG->localcachedir to fast local filesystem on each node.
#Use one big central memcached server for all shared caches that support it.
#Use local memcached instances on cluster nodes for local caches that support it.
#Store user sessions in one shared server eg Redis. (See [[Session_handling]] for details)
#Use fast local directory for dirroot on each cluster node.
#Use dynamic cluster node management.
#Use transparent proxy servers.

==Upgrade procedure==

#Disable load balancer.
#Upgrade dirroot files on master server.
#Perform CLI upgrade.
#Manually reset all caches in cluster nodes - restart web server, delete localcachedir and temp directories, restart memcached, etc. Or delete all cluster nodes and create nodes from a new template.
#Enable load balancer.

==Step by step guide for server clustering in Moodle 2.6==
From hardware and performance forum thread [https://moodle.org/mod/forum/discuss.php?d=251547 https://moodle.org/mod/forum/discuss.php?d=251547]

* 1 Determine your specific need for caches. This involves the concepts of shared cache or local cache, disk based cache or server based cache or protocol specific cache like Memcached or MongoDB.
** 1.1 If you have a slow shared disk, you might benefit from a local disk cache.
** 1.2 If you have only a few users on your Moodle site, you might not want to set up a Memcached service, even if the acceleration that Memcached provides, is very significant for the user experience.
** 1.3 If you want to do anything in your power for accelerating the site, you might consider MongoDB.
* 2 Configure the caches, test them and verify them. There is room for improvement in the examples for cache configuration. This is probably the most difficult step.
* 3 Install the cache support on server level. This may involve installing php modules or config for php modules.
* 4 Create a cache instance in MUC here: example.com/cache/admin.php?action=addstore&plugin=memcached
** 4.1 Give the cache instance some arbitrary name.
** 4.2 All other fields have a question mark that can be clicked on for excellent help that tells you what to fill in, and the syntax (very important).
** 4.3 The result should be a Configured Store Instance, with the name of your choice.
* 5 The final step is to deploy the created cache instances by Editing Mappings for e.g. Language string cache in the list of Known cache definitions.
** 5.1 While experimenting with this, I have found it a life saver to open a separate browser window, where the default setting is selected, so I just need to click on the Save button to revert the setting, just in case I lose contact with the site.
** 5.2 Select the name of your configured store instance from the dropdown list and click on the Save button.
** 5.3 Test the new cache setting. If you lose contact with the site or it behaves weirdly, try using the trick in step 1. In case of emergency you might remove the cache config file (muc/config.php) in the folder pointed to by $CFG->dataroot . It seems that Moodle writes a new default config file if it is missing.

==See also==
*[[Performance recommendations]]
*[[Caching]]
*[[:dev:Server clustering improvements proposal]]
*Hardware and performance forum thread [https://moodle.org/mod/forum/discuss.php?d=251547https://moodle.org/mod/forum/discuss.php?d=251547]
*How to Cluster Moodle on Multiple Servers for High Availability and Scalability [http://www.severalnines.com/blog/clustering-moodle-multiple-servers-high-availability-scalability]
* PHP session cache in a cluster
** https://www.digitalocean.com/community/tutorials/how-to-set-up-a-redis-server-as-a-session-handler-for-php-on-ubuntu-14-04
** https://inchoo.net/magento/programming-magento/session-storage-php

Server cluster

2021-02-08T22:21:30Z

Brendanheywood: /* $CFG->localcachedir */

This page is going to describe some basic information related to server clustering...

==Requirements==

* database server - ACID compliant, for example PostgreSQL and MariaDB
* main server that is able to share dataroot - locking support recommended, for example NFS
* load balancer - for example Nginx
* cluster nodes - web servers
* Redis (or Memcached) server for shared MUC caches

Note: this guide is not intended for Windows OS or any other Microsoft technologies.

==Initial installation==

# Perform standard CLI installation on the main server using shared database and dataroot directory.
# Setup web servers on cluster nodes - use local dirroot and shared database and dataroot.
# Configure load balancing.

==Related config.php settings==

===$CFG->wwwroot===
It must be the same on all nodes, it must be the public facing URL. It cannot be dynamic.

===$CFG->sslproxy===
Enable if you have https:// wwwroot but the SSL is done by load-balancer instead of web server.

Please note that it is not compatible with $CFG->loginhttps. This is because in order for loginhttps to work, we need to know the original request, and whether it was http or https. This allows us to only provide the login form over ssl. The original request is lost when made through a "reverse" proxy / load balancer, so we cannot determine what protocol the request was made in. So we can't provide most of moodle over http and the login page over https.

Enable ''Secure cookies only'' to make your site really secure, without it cookie stealing is still trivial.

===$CFG->reverseproxy===
Enable if your nodes are accessed via different URL.

Please note that it is not compatible with $CFG->loginhttps. This is because in order for loginhttps to work, we need to know the original request, and whether it was http or https. This allows us to only provide the login form over ssl. The original request is lost when made through a "reverse" proxy / load balancer, so we cannot determine what protocol the request was made in. So we can't provide most of moodle over http and the login page over https.

===$CFG->dirroot===
It is strongly recommended that $CFG->dirroot (which is automatically set via realpath(config.php)) contains the same path on all nodes. It does not need to point to the same shared directory though. The reason is that some some low level code may use the dirroot value for cache invalidation.

The simplest solution is to have the same directory structure on each cluster node and synchronise these during each upgrade.

The dirroot should be always read only for apache process because otherwise built in plugin installation and uninstallation would get the nodes out of sync.

===$CFG->dataroot===

This '''MUST''' be a shared directory where each cluster node is accessing the files directly. It must be very reliable, administrators cannot manipulate files directly.

Locking support is not required, if any code tries to use file locks in dataroot outside of cachedir or muc directory it is a bug.

===$CFG->tempdir===

This directory '''MUST''' be shared by all cluster nodes. Locking is required.

===$CFG->cachedir===

This directory '''MUST''' be shared by all cluster nodes. Locking is required.

===$CFG->localcachedir===

The difference from $CFG->cachedir is that the directory does not have to be shared by all cluster nodes, the file contents do not change. Use local fast filesystem on each cluster node.

The nature of this path is very slow moving files that stay for a long time and are written once and never overwritten.

===$CFG->localrequestdir===

By default this is created inside /tmp or whatever sys_get_temp_dir() returns and is generally already local disk and not shared with other nodes. This directory holds temporary folders and files which only exist for the duration of a single http request. If you do change this use local fast filesystem on each cluster node.

==Performance recommendations==

#Use OPcache extension on all cluster nodes.
#Set $CFG->localcachedir to fast local filesystem on each node.
#Use one big central memcached server for all shared caches that support it.
#Use local memcached instances on cluster nodes for local caches that support it.
#Store user sessions in one shared memcached server. (See [[Session_handling]] for details)
#Use fast local directory for dirroot on each cluster node.
#Use dynamic cluster node management.
#Use transparent proxy servers.

==Upgrade procedure==

#Disable load balancer.
#Upgrade dirroot files on master server.
#Perform CLI upgrade.
#Manually reset all caches in cluster nodes - restart web server, delete localcachedir and temp directories, restart memcached, etc. Or delete all cluster nodes and create nodes from a new template.
#Enable load balancer.

==Step by step guide for server clustering in Moodle 2.6==
From hardware and performance forum thread [https://moodle.org/mod/forum/discuss.php?d=251547 https://moodle.org/mod/forum/discuss.php?d=251547]

* 1 Determine your specific need for caches. This involves the concepts of shared cache or local cache, disk based cache or server based cache or protocol specific cache like Memcached or MongoDB.
** 1.1 If you have a slow shared disk, you might benefit from a local disk cache.
** 1.2 If you have only a few users on your Moodle site, you might not want to set up a Memcached service, even if the acceleration that Memcached provides, is very significant for the user experience.
** 1.3 If you want to do anything in your power for accelerating the site, you might consider MongoDB.
* 2 Configure the caches, test them and verify them. There is room for improvement in the examples for cache configuration. This is probably the most difficult step.
* 3 Install the cache support on server level. This may involve installing php modules or config for php modules.
* 4 Create a cache instance in MUC here: example.com/cache/admin.php?action=addstore&plugin=memcached
** 4.1 Give the cache instance some arbitrary name.
** 4.2 All other fields have a question mark that can be clicked on for excellent help that tells you what to fill in, and the syntax (very important).
** 4.3 The result should be a Configured Store Instance, with the name of your choice.
* 5 The final step is to deploy the created cache instances by Editing Mappings for e.g. Language string cache in the list of Known cache definitions.
** 5.1 While experimenting with this, I have found it a life saver to open a separate browser window, where the default setting is selected, so I just need to click on the Save button to revert the setting, just in case I lose contact with the site.
** 5.2 Select the name of your configured store instance from the dropdown list and click on the Save button.
** 5.3 Test the new cache setting. If you lose contact with the site or it behaves weirdly, try using the trick in step 1. In case of emergency you might remove the cache config file (muc/config.php) in the folder pointed to by $CFG->dataroot . It seems that Moodle writes a new default config file if it is missing.

==See also==
*[[Performance recommendations]]
*[[Caching]]
*[[:dev:Server clustering improvements proposal]]
*Hardware and performance forum thread [https://moodle.org/mod/forum/discuss.php?d=251547https://moodle.org/mod/forum/discuss.php?d=251547]
*How to Cluster Moodle on Multiple Servers for High Availability and Scalability [http://www.severalnines.com/blog/clustering-moodle-multiple-servers-high-availability-scalability]
* PHP session cache in a cluster
** https://www.digitalocean.com/community/tutorials/how-to-set-up-a-redis-server-as-a-session-handler-for-php-on-ubuntu-14-04
** https://inchoo.net/magento/programming-magento/session-storage-php

Configuration file

2021-02-08T22:09:49Z

Brendanheywood: /* Forcing the value of admin settings */

{{Installing Moodle}}
The name for Moodle's configuration file is config.php. The file is located in the moodle directory. It is not included in the Moodle download packages and is created by the installation process from the template file config-dist.php (which is included in Moodle packages).

==config-dist.php==
Although the installation process creates the config.php file for you, there may be times when you want to do this yourself. A sample config file, called config-dist.php, is shipped with Moodle.

To get started simply copy config-dist.php to config.php, then edit config.php with you favourite editor. The file is very well commented. The important options (which you must supply) are all nearer the top. Other less common options are further down.

==Setting $CFG->wwwroot correctly==
This setting must be a fixed URL (a string constant) that points to your site. Do not try to set this with any PHP code that can generate a variable URL. This is not supported, can cause strange problems and will stop command line scripts working completely. If your site is accessed from different IP addresses this should be done with a split DNS, see [[Masquerading]]

If you change your site from http to https, you '''MUST''' update this setting. If you don’t, you will have problems - for example (but not limited to) css scripts won’t load properly and you will also experience problems with logging in to your site. Also see [[Transitioning_to_HTTPS]]

==Enabling password salting==

See [[Password salting]].

==Including passwords in backups==

Hashed user passwords are no longer saved in backup files containing user data.

If you really need passwords to be saved (in the rare case of restoring a [[Backup of user data|backup with user data]] to a different site), the following line may be added to config.php:

$CFG->includeuserpasswordsinbackup = true;

Note regarding restoring Moodle 2.5 backups to sites with old PHP versions:

Because bcrypt is not supported in PHP versions below 5.3.7, course backups made using the $CFG->includeuserpasswordsinbackup setting on a site using PHP version 5.3.7+ that are subsequently restored to a site with PHP version < 5.3.7 will require a password reset.

==Changing default block layout for new courses==

See [[Block layout]].

==Adding extra theme directory location==
It is possible to add an extra themes directory stored outside of $CFG->dirroot. This local directory does not have to be accessible from internet. Themes placed in the directory specified by these variables will then be available for selection using the theme selector.

For example, should you wish to place extra themes in a subdirectory called 'my_moodle_themes', your config.php might look like this:
<pre>
$CFG->wwwroot = 'http://my.moodle.site.edu';
$CFG->dirroot = '/var/www/my.moodle.site.edu/public_html';
$CFG->themedir = $CFG->dirroot . '/my_moodle_themes';
</pre>

==Disabling update notifications==

See [[Notifications]].

==Enabling debugging==

See [[Debugging]].

==Forcing the value of admin settings==

As explained in config-dist.php, it is possible to specify normal admin settings here, the point is that they can not be changed through the standard admin settings pages any more. Just set the value in config.php like:

<code php>
$CFG->showuseridentity = 'email,idnumber,username';
$CFG->preventexecpath = true;
$CFG->pathtodu = "/usr/bin/du";
$CFG->pathtodot = "/usr/bin/dot";
$CFG->pathtogs = "/usr/bin/gs";
</code>

Configuration for plugins can also be forced by the syntax is different, eg continuing the example above for security to always hard coded paths to all executable files:

<code php>
$CFG->forced_plugin_settings['filter_text']['pathconvert'] = '/usr/bin/convert';
$CFG->forced_plugin_settings['filter_text']['pathdvips'] = '/usr/bin/dvips';
$CFG->forced_plugin_settings['filter_text']['pathdvisvgm'] = '/usr/bin/dvisvgm';
$CFG->forced_plugin_settings['filter_text']['pathlatex'] = '/usr/bin/latex';
</code>

==See also==

* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=137889 Moodle Salting] forum discussion

[[de:Konfigurationsdatei]]
[[es:config.php]]
[[fr:Fichier de configuration]]
[[ja:設定ファイル]]

Cron with Unix or Linux

2021-01-31T22:18:56Z

Brendanheywood: /* Logging and monitoring */

{{Installing Moodle}}
On Unix and Linux use the built in ''cron'' program which is standard on nearly all systems. You are required to add a command to the 'crontab' (the table that holds cron commands) for the web server user.

There are two different methods that can be used to invoke the Moodle cron process:

'''NOTE:''' The commands shown need to be added to the crontab to function (described in a moment). However, you can - and should - run them on the command line to check they work first.

== Method 1: The command line (cli) cron ==

If you have a choice, this is normally the best way to run Moodle cron.

PHP is also capable of running programs directly from the command line. Your system needs to be set up to do this; specifically you need the 'CLI' version of PHP to be installed. Most systems with PHP installed will have this by default. If you have the PHP CLI version installed then this is the recommended method of invoking cron. The correct command will be something like...
<pre>
/usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
(substitute the correct path to moodle and for php as required)

You can simply type this on the command line this to see if it works. If you are not sure about the path to PHP you can type "<code>which php</code>".

'''Tip:''': If you have problems, see the [[PHP]] page. In particular, suspect an alternate php.ini for the CLI PHP command which may not have suitable settings.

== Method 2: Web based cron ==

'''NOTE:''' In order to use the web based cron script you must first check [[Cron settings]] to make sure this method is permitted.

The idea is to call the following web page (you can try this from your browser):
<pre>
http://url.of.your/moodle/admin/cron.php
</pre>

A command line (text based) browser is needed to run this on the server. Possibilities are as follows (OSX, for example, only ships with curl)...
<pre>
/usr/bin/wget -q -O /dev/null/ http://url.of.your/moodle/admin/cron.php
</pre>
(no output is displayed - remove the ''-O /dev/null/'' to test)

...OR...

<pre>
/usr/bin/curl http://url.of.your/moodle/admin/cron.php -o /dev/null/ -silent
</pre>
(no output is displayed - remove the ''-o /dev/null/ -silent'' to test)

==Using the crontab program on Unix/Linux==

Once you have selected (and tested!) an appropriate command to invoke the Moodle cron it must be added to the web users 'crontab' to schedule it to run regularly. 'Crontab' is both a file containing the user's cron commands and is also the name of the (command line) program used to edit it. Use the following command (as root) substituting the correct user in place of 'www-data' (e.g. 'apache' for Centos, 'www-data' for Debian/Ubuntu, '_www' for macOS—Google will know!)
<pre>
# crontab -u www-data -e
</pre>
This will bring up an editor window (the first time it may ask you which editor to use). Add the command onto the end of the file in this way (it may be empty or it may have some instructional comments):
<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
The first five * entries specify the times, followed by the command, to run. This says to run the command as often as possible, ie every minute.

See https://en.wikipedia.org/wiki/Cron#CRON_expression for details on cron expressions.

== Logging and monitoring ==

Ideally you should also be logging the output of cron somewhere and monitoring it for issues. You can monitor the overall status of cron to make sure there are no errors by visiting:

Site administration / Reports / System status (/report/status/index.php)

You can also wire this status report up to tools like Icinga / Nagios using the Check API (https://docs.moodle.org/dev/Check_API) cli commands or with the help of plugins like https://github.com/catalyst/moodle-tool_heartbeat.

<code sh>
/admin/cli/checks.php
</code>

If there are errors then you can get more details for recently run tasks from the Logs column on the Scheduled task page, but this won't show adhoc task failures:

Site administration / Server / Tasks / Scheduled tasks (/admin/tool/task/scheduledtasks.php)

To see adhoc task failures you either need to rerun the task manually yourself and see the errors, or you need to have already collected the logs for review. For a Moodle running on a single box you could log to a simple log file, or for a cluster you might want to use syslogd or similar, eg:

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php 2>&1 | /usr/bin/logger ...
</pre>

== Low latency adhoc tasks ==

Each time cron is run, after the scheduled tasks the adhoc tasks are also run. While scheduled tasks can run at most once a minute, adhoc tasks can be queued at any moment, and generally you want them processed as soon as possible and to not have to wait for the scheduled task to run first. If you only run the normal admin/cli/cron.php then not only might it have to wait to process all the scheduled tasks first, if it has already finished you will have to wait until the next minute for cron to start again for it to be processed.

Instead you can run one or more dedicated adhoc task processors which run in parallel to the main cron process.

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...
</pre>

Starting from Moodle 3.9 the --keep-alive option runs like a daemon so when the queue is empty rather then exiting it waits for new tasks to be queued so it can start processing as soon as possible.

== Scaling up cron with multiple processes ==

As your site grows many of the scheduled tasks will take longer to complete, and also there will be more adhoc tasks queued which need to be processed. The cron system is designed to work in parallel but each individual process can only process one task at a time so you must run multiple cron cli's. You can generally run a fairly high number of cron processes on a dedicated cron instance before needing to run multiple cron instances. To run more than one process simply spawn multiple cron processes each minute:

<code>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
...
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...
</code>

It can be especially important to increase the number of adhoc_task.php processes as certain plugins and systems can generate very large numbers of adhoc tasks, or tasks that can take a long time to process. Especially tasks like document conversions and automated backups can build up more quickly than they are processed if they are left on default settings.

By default only 3 scheduled tasks and 3 adhoc tasks can be run concurrently so as you add more processes you need to increase the level of allowed concurrency:

Site administration > Server > Tasks > Task processing

<code php>
config.php:
$CFG->task_scheduled_concurrency_limit = 20; // Defaults to 3
$CFG->task_adhoc_concurrency_limit = 50; // Defaults to 3
</code>

Whatever you set these too make sure the server(s) hosting them can comfortably handle this many processes. Often the bottleneck will be a shared service, usually the database.

You may find that certain types of very long running tasks will consume all the available task processes which means no other tasks will run. eg if you have 5 cli processes, but in the task queue there are 20 adhoc tasks for an automated backup, each of which will take ten minutes to complete, then very quickly all 5 processes will be consumed by backups and nothing else. Other small very fast and light tasks like a document conversion or forum emails will not get sent until the backups are complete and a process frees up. To manage this you can limit the concurrency of specific types of adhoc tasks. A good rule of thumb is that if all of the 'heavy' tasks consume all of their own limits then you should still have another few processes standing by on idle waiting for anything else which may be added to the queue.

Automated backups are the worst known offender, so hypothetically if you are running 50 adhoc task processes concurrently a reasonable restriction might be to cap the backups to consume no more than half of those processes, ie 25 at most:

<code php>
config.php:
$CFG->task_concurrency_limit = [
'core\task\course_backup_task' => 25,
'core_course\task\course_delete_modules' => 5,
];
</code>

== See also ==

* [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]
* [http://www.easycron.com/predictor Predicting Cron job's run time]

[[es:Cron con Unix o Linux]]

Cron with Unix or Linux

2021-01-31T22:13:48Z

Brendanheywood: /* Using the crontab program on Unix/Linux */

{{Installing Moodle}}
On Unix and Linux use the built in ''cron'' program which is standard on nearly all systems. You are required to add a command to the 'crontab' (the table that holds cron commands) for the web server user.

There are two different methods that can be used to invoke the Moodle cron process:

'''NOTE:''' The commands shown need to be added to the crontab to function (described in a moment). However, you can - and should - run them on the command line to check they work first.

== Method 1: The command line (cli) cron ==

If you have a choice, this is normally the best way to run Moodle cron.

PHP is also capable of running programs directly from the command line. Your system needs to be set up to do this; specifically you need the 'CLI' version of PHP to be installed. Most systems with PHP installed will have this by default. If you have the PHP CLI version installed then this is the recommended method of invoking cron. The correct command will be something like...
<pre>
/usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
(substitute the correct path to moodle and for php as required)

You can simply type this on the command line this to see if it works. If you are not sure about the path to PHP you can type "<code>which php</code>".

'''Tip:''': If you have problems, see the [[PHP]] page. In particular, suspect an alternate php.ini for the CLI PHP command which may not have suitable settings.

== Method 2: Web based cron ==

'''NOTE:''' In order to use the web based cron script you must first check [[Cron settings]] to make sure this method is permitted.

The idea is to call the following web page (you can try this from your browser):
<pre>
http://url.of.your/moodle/admin/cron.php
</pre>

A command line (text based) browser is needed to run this on the server. Possibilities are as follows (OSX, for example, only ships with curl)...
<pre>
/usr/bin/wget -q -O /dev/null/ http://url.of.your/moodle/admin/cron.php
</pre>
(no output is displayed - remove the ''-O /dev/null/'' to test)

...OR...

<pre>
/usr/bin/curl http://url.of.your/moodle/admin/cron.php -o /dev/null/ -silent
</pre>
(no output is displayed - remove the ''-o /dev/null/ -silent'' to test)

==Using the crontab program on Unix/Linux==

Once you have selected (and tested!) an appropriate command to invoke the Moodle cron it must be added to the web users 'crontab' to schedule it to run regularly. 'Crontab' is both a file containing the user's cron commands and is also the name of the (command line) program used to edit it. Use the following command (as root) substituting the correct user in place of 'www-data' (e.g. 'apache' for Centos, 'www-data' for Debian/Ubuntu, '_www' for macOS—Google will know!)
<pre>
# crontab -u www-data -e
</pre>
This will bring up an editor window (the first time it may ask you which editor to use). Add the command onto the end of the file in this way (it may be empty or it may have some instructional comments):
<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
The first five * entries specify the times, followed by the command, to run. This says to run the command as often as possible, ie every minute.

See https://en.wikipedia.org/wiki/Cron#CRON_expression for details on cron expressions.

== Logging and monitoring ==

Ideally you should also be logging the output of cron somewhere and monitoring it for issues. You can monitor the overall status of cron to make sure there are no errors by visiting:

Site administration /Reports / System status (/report/status/index.php)

If there are errors then you can get more details for recently run tasks from the Logs column on the Scheduled task page, but this won't show adhoc task failures:

Site administration / Server / Tasks / Scheduled tasks (/admin/tool/task/scheduledtasks.php)

To see adhoc task failures you either need to rerun the task manually yourself and see the errors, or you need to have already collected the logs for review. For a Moodle running on a single box you could log to a simple log file, or for a cluster you might want to use syslogd or similar, eg:

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php 2>&1 | /usr/bin/logger ...
</pre>

== Low latency adhoc tasks ==

Each time cron is run, after the scheduled tasks the adhoc tasks are also run. While scheduled tasks can run at most once a minute, adhoc tasks can be queued at any moment, and generally you want them processed as soon as possible and to not have to wait for the scheduled task to run first. If you only run the normal admin/cli/cron.php then not only might it have to wait to process all the scheduled tasks first, if it has already finished you will have to wait until the next minute for cron to start again for it to be processed.

Instead you can run one or more dedicated adhoc task processors which run in parallel to the main cron process.

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...
</pre>

Starting from Moodle 3.9 the --keep-alive option runs like a daemon so when the queue is empty rather then exiting it waits for new tasks to be queued so it can start processing as soon as possible.

== Scaling up cron with multiple processes ==

As your site grows many of the scheduled tasks will take longer to complete, and also there will be more adhoc tasks queued which need to be processed. The cron system is designed to work in parallel but each individual process can only process one task at a time so you must run multiple cron cli's. You can generally run a fairly high number of cron processes on a dedicated cron instance before needing to run multiple cron instances. To run more than one process simply spawn multiple cron processes each minute:

<code>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
...
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...
</code>

It can be especially important to increase the number of adhoc_task.php processes as certain plugins and systems can generate very large numbers of adhoc tasks, or tasks that can take a long time to process. Especially tasks like document conversions and automated backups can build up more quickly than they are processed if they are left on default settings.

By default only 3 scheduled tasks and 3 adhoc tasks can be run concurrently so as you add more processes you need to increase the level of allowed concurrency:

Site administration > Server > Tasks > Task processing

<code php>
config.php:
$CFG->task_scheduled_concurrency_limit = 20; // Defaults to 3
$CFG->task_adhoc_concurrency_limit = 50; // Defaults to 3
</code>

Whatever you set these too make sure the server(s) hosting them can comfortably handle this many processes. Often the bottleneck will be a shared service, usually the database.

You may find that certain types of very long running tasks will consume all the available task processes which means no other tasks will run. eg if you have 5 cli processes, but in the task queue there are 20 adhoc tasks for an automated backup, each of which will take ten minutes to complete, then very quickly all 5 processes will be consumed by backups and nothing else. Other small very fast and light tasks like a document conversion or forum emails will not get sent until the backups are complete and a process frees up. To manage this you can limit the concurrency of specific types of adhoc tasks. A good rule of thumb is that if all of the 'heavy' tasks consume all of their own limits then you should still have another few processes standing by on idle waiting for anything else which may be added to the queue.

Automated backups are the worst known offender, so hypothetically if you are running 50 adhoc task processes concurrently a reasonable restriction might be to cap the backups to consume no more than half of those processes, ie 25 at most:

<code php>
config.php:
$CFG->task_concurrency_limit = [
'core\task\course_backup_task' => 25,
'core_course\task\course_delete_modules' => 5,
];
</code>

== See also ==

* [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]
* [http://www.easycron.com/predictor Predicting Cron job's run time]

[[es:Cron con Unix o Linux]]

Cron with Unix or Linux

2021-01-28T13:53:58Z

Brendanheywood: /* Scaling up cron with multiple processes */

{{Installing Moodle}}
On Unix and Linux use the built in ''cron'' program which is standard on nearly all systems. You are required to add a command to the 'crontab' (the table that holds cron commands) for the web server user.

There are two different methods that can be used to invoke the Moodle cron process:

'''NOTE:''' The commands shown need to be added to the crontab to function (described in a moment). However, you can - and should - run them on the command line to check they work first.

== Method 1: The command line (cli) cron ==

If you have a choice, this is normally the best way to run Moodle cron.

PHP is also capable of running programs directly from the command line. Your system needs to be set up to do this; specifically you need the 'CLI' version of PHP to be installed. Most systems with PHP installed will have this by default. If you have the PHP CLI version installed then this is the recommended method of invoking cron. The correct command will be something like...
<pre>
/usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
(substitute the correct path to moodle and for php as required)

You can simply type this on the command line this to see if it works. If you are not sure about the path to PHP you can type "<code>which php</code>".

'''Tip:''': If you have problems, see the [[PHP]] page. In particular, suspect an alternate php.ini for the CLI PHP command which may not have suitable settings.

== Method 2: Web based cron ==

'''NOTE:''' In order to use the web based cron script you must first check [[Cron settings]] to make sure this method is permitted.

The idea is to call the following web page (you can try this from your browser):
<pre>
http://url.of.your/moodle/admin/cron.php
</pre>

A command line (text based) browser is needed to run this on the server. Possibilities are as follows (OSX, for example, only ships with curl)...
<pre>
/usr/bin/wget -q -O /dev/null/ http://url.of.your/moodle/admin/cron.php
</pre>
(no output is displayed - remove the ''-O /dev/null/'' to test)

...OR...

<pre>
/usr/bin/curl http://url.of.your/moodle/admin/cron.php -o /dev/null/ -silent
</pre>
(no output is displayed - remove the ''-o /dev/null/ -silent'' to test)

==Using the crontab program on Unix/Linux==

Once you have selected (and tested!) an appropriate command to invoke the Moodle cron it must be added to the web users 'crontab' to schedule it to run regularly. 'Crontab' is both a file containing the user's cron commands and is also the name of the (command line) program used to edit it. Use the following command (as root) substituting the correct user in place of 'www-data' (e.g. 'apache' for Centos, 'www-data' for Debian/Ubuntu, '_www' for macOS—Google will know!)
<pre>
# crontab -u www-data -e
</pre>
This will bring up an editor window (the first time it may ask you which editor to use). Add the command onto the end of the file in this way (it may be empty or it may have some instructional comments):
<pre>
*/1 * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
The first five entries specify the times, followed by the command, to run. This says to run the command every minute which is normally ok. On a hosted system you may get complaints if you do not run it a lot less often (e.g. to run every two hours use '0 */2 * * *' for the first five entries). If you want to use the wget/curl version, the first five entries remain the same - just change the command part.

== Low latency adhoc tasks ==

Each time cron is run, after the scheduled tasks the adhoc tasks are also run. While scheduled tasks can run at most once a minute, adhoc tasks can be queued at any moment, and generally you want them processed as soon as possible and to not have to wait for the scheduled task to run first. If you only run the normal admin/cli/cron.php then not only might it have to wait to process all the scheduled tasks first, if it has already finished you will have to wait until the next minute for cron to start again for it to be processed.

Instead you can run one or more dedicated adhoc task processors which run in parallel to the main cron process.

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...
</pre>

Starting from Moodle 3.9 the --keep-alive option runs like a daemon so when the queue is empty rather then exiting it waits for new tasks to be queued so it can start processing as soon as possible.

== Scaling up cron with multiple processes ==

As your site grows many of the scheduled tasks will take longer to complete, and also there will be more adhoc tasks queued which need to be processed. The cron system is designed to work in parallel but each individual process can only process one task at a time so you must run multiple cron cli's. You can generally run a fairly high number of cron processes on a dedicated cron instance before needing to run multiple cron instances. To run more than one process simply spawn multiple cron processes each minute:

<code>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
...
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...
</code>

It can be especially important to increase the number of adhoc_task.php processes as certain plugins and systems can generate very large numbers of adhoc tasks, or tasks that can take a long time to process. Especially tasks like document conversions and automated backups can build up more quickly than they are processed if they are left on default settings.

By default only 3 scheduled tasks and 3 adhoc tasks can be run concurrently so as you add more processes you need to increase the level of allowed concurrency:

Site administration > Server > Tasks > Task processing

<code php>
config.php:
$CFG->task_scheduled_concurrency_limit = 20; // Defaults to 3
$CFG->task_adhoc_concurrency_limit = 50; // Defaults to 3
</code>

Whatever you set these too make sure the server(s) hosting them can comfortably handle this many processes. Often the bottleneck will be a shared service, usually the database.

You may find that certain types of very long running tasks will consume all the available task processes which means no other tasks will run. eg if you have 5 cli processes, but in the task queue there are 20 adhoc tasks for an automated backup, each of which will take ten minutes to complete, then very quickly all 5 processes will be consumed by backups and nothing else. Other small very fast and light tasks like a document conversion or forum emails will not get sent until the backups are complete and a process frees up. To manage this you can limit the concurrency of specific types of adhoc tasks. A good rule of thumb is that if all of the 'heavy' tasks consume all of their own limits then you should still have another few processes standing by on idle waiting for anything else which may be added to the queue.

Automated backups are the worst known offender, so hypothetically if you are running 50 adhoc task processes concurrently a reasonable restriction might be to cap the backups to consume no more than half of those processes, ie 25 at most:

<code php>
config.php:
$CFG->task_concurrency_limit = [
'core\task\course_backup_task' => 25,
'core_course\task\course_delete_modules' => 5,
];
</code>

== See also ==

* [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]
* [http://www.easycron.com/predictor Predicting Cron job's run time]

[[es:Cron con Unix o Linux]]

Cron with Unix or Linux

2021-01-28T13:50:28Z

Brendanheywood: /* Scaling up cron with multiple processes */

{{Installing Moodle}}
On Unix and Linux use the built in ''cron'' program which is standard on nearly all systems. You are required to add a command to the 'crontab' (the table that holds cron commands) for the web server user.

There are two different methods that can be used to invoke the Moodle cron process:

'''NOTE:''' The commands shown need to be added to the crontab to function (described in a moment). However, you can - and should - run them on the command line to check they work first.

== Method 1: The command line (cli) cron ==

If you have a choice, this is normally the best way to run Moodle cron.

PHP is also capable of running programs directly from the command line. Your system needs to be set up to do this; specifically you need the 'CLI' version of PHP to be installed. Most systems with PHP installed will have this by default. If you have the PHP CLI version installed then this is the recommended method of invoking cron. The correct command will be something like...
<pre>
/usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
(substitute the correct path to moodle and for php as required)

You can simply type this on the command line this to see if it works. If you are not sure about the path to PHP you can type "<code>which php</code>".

'''Tip:''': If you have problems, see the [[PHP]] page. In particular, suspect an alternate php.ini for the CLI PHP command which may not have suitable settings.

== Method 2: Web based cron ==

'''NOTE:''' In order to use the web based cron script you must first check [[Cron settings]] to make sure this method is permitted.

The idea is to call the following web page (you can try this from your browser):
<pre>
http://url.of.your/moodle/admin/cron.php
</pre>

A command line (text based) browser is needed to run this on the server. Possibilities are as follows (OSX, for example, only ships with curl)...
<pre>
/usr/bin/wget -q -O /dev/null/ http://url.of.your/moodle/admin/cron.php
</pre>
(no output is displayed - remove the ''-O /dev/null/'' to test)

...OR...

<pre>
/usr/bin/curl http://url.of.your/moodle/admin/cron.php -o /dev/null/ -silent
</pre>
(no output is displayed - remove the ''-o /dev/null/ -silent'' to test)

==Using the crontab program on Unix/Linux==

Once you have selected (and tested!) an appropriate command to invoke the Moodle cron it must be added to the web users 'crontab' to schedule it to run regularly. 'Crontab' is both a file containing the user's cron commands and is also the name of the (command line) program used to edit it. Use the following command (as root) substituting the correct user in place of 'www-data' (e.g. 'apache' for Centos, 'www-data' for Debian/Ubuntu, '_www' for macOS—Google will know!)
<pre>
# crontab -u www-data -e
</pre>
This will bring up an editor window (the first time it may ask you which editor to use). Add the command onto the end of the file in this way (it may be empty or it may have some instructional comments):
<pre>
*/1 * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
The first five entries specify the times, followed by the command, to run. This says to run the command every minute which is normally ok. On a hosted system you may get complaints if you do not run it a lot less often (e.g. to run every two hours use '0 */2 * * *' for the first five entries). If you want to use the wget/curl version, the first five entries remain the same - just change the command part.

== Low latency adhoc tasks ==

Each time cron is run, after the scheduled tasks the adhoc tasks are also run. While scheduled tasks can run at most once a minute, adhoc tasks can be queued at any moment, and generally you want them processed as soon as possible and to not have to wait for the scheduled task to run first. If you only run the normal admin/cli/cron.php then not only might it have to wait to process all the scheduled tasks first, if it has already finished you will have to wait until the next minute for cron to start again for it to be processed.

Instead you can run one or more dedicated adhoc task processors which run in parallel to the main cron process.

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...
</pre>

Starting from Moodle 3.9 the --keep-alive option runs like a daemon so when the queue is empty rather then exiting it waits for new tasks to be queued so it can start processing as soon as possible.

== Scaling up cron with multiple processes ==

As your site grows many of the scheduled tasks will take longer to complete, and also there will be more adhoc tasks queued which need to be processed. The cron system is designed to work in parallel but each individual process can only process one task at a time so you must run multiple cron cli's. You can generally run a fairly high number of cron processes on a dedicated cron instance before needing to run multiple cron instances. To run more than one process simply spawn multiple cron processes each minute:

<code>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
...
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...
</code>

It can be especially important to increase the number of adhoc_task.php processes as certain plugins and systems can generate very large numbers of adhoc tasks, or tasks that can take a long time to process. Especially tasks like document conversions and automated backups can build up more quickly than they are processed if they are left on default settings.

By default only 3 scheduled tasks and 3 adhoc tasks can be run concurrently so as you add more processes you need to increase the level of allowed concurrency:

Site administration > Server > Tasks > Task processing

<code php>
config.php:
$CFG->task_scheduled_concurrency_limit = 20; // Defaults to 3
$CFG->task_adhoc_concurrency_limit = 50; // Defaults to 3
</code>

Whatever you set these too make sure the server(s) hosting them can comfortably handle this many processes. Often the bottleneck will be a shared service, usually the database.

You may find that certain types of very long running tasks will consume all the available task processes which means no other tasks will run. eg if you have 5 cli processes, but in the task queue there are 20 adhoc tasks for an automated backup, each of which will take ten minutes to complete, then very quickly all 5 processes will be consumed by backups and nothing else. Other small very fast and light tasks like a document conversion or forum emails will not get sent until the backups are complete and a process frees up. To manage this you can limit the concurrency of specific types of adhoc tasks. A good rule of thumb is that if all of the 'heavy' tasks consume all of their own limits then you should still have another few processes standing by on idle waiting for anything else which may be added to the queue.

<code php>
config.php:
$CFG->task_concurrency_limit = [
'core\task\course_backup_task' => 28,
'core_course\task\course_delete_modules' => 6,
];
</code>

== See also ==

* [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]
* [http://www.easycron.com/predictor Predicting Cron job's run time]

[[es:Cron con Unix o Linux]]

Cron with Unix or Linux

2021-01-28T10:21:04Z

Brendanheywood: Removed all /dev/null piping

{{Installing Moodle}}
On Unix and Linux use the built in ''cron'' program which is standard on nearly all systems. You are required to add a command to the 'crontab' (the table that holds cron commands) for the web server user.

There are two different methods that can be used to invoke the Moodle cron process:

'''NOTE:''' The commands shown need to be added to the crontab to function (described in a moment). However, you can - and should - run them on the command line to check they work first.

== Method 1: The command line (cli) cron ==

If you have a choice, this is normally the best way to run Moodle cron.

PHP is also capable of running programs directly from the command line. Your system needs to be set up to do this; specifically you need the 'CLI' version of PHP to be installed. Most systems with PHP installed will have this by default. If you have the PHP CLI version installed then this is the recommended method of invoking cron. The correct command will be something like...
<pre>
/usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
(substitute the correct path to moodle and for php as required)

You can simply type this on the command line this to see if it works. If you are not sure about the path to PHP you can type "<code>which php</code>".

'''Tip:''': If you have problems, see the [[PHP]] page. In particular, suspect an alternate php.ini for the CLI PHP command which may not have suitable settings.

== Method 2: Web based cron ==

'''NOTE:''' In order to use the web based cron script you must first check [[Cron settings]] to make sure this method is permitted.

The idea is to call the following web page (you can try this from your browser):
<pre>
http://url.of.your/moodle/admin/cron.php
</pre>

A command line (text based) browser is needed to run this on the server. Possibilities are as follows (OSX, for example, only ships with curl)...
<pre>
/usr/bin/wget -q -O /dev/null/ http://url.of.your/moodle/admin/cron.php
</pre>
(no output is displayed - remove the ''-O /dev/null/'' to test)

...OR...

<pre>
/usr/bin/curl http://url.of.your/moodle/admin/cron.php -o /dev/null/ -silent
</pre>
(no output is displayed - remove the ''-o /dev/null/ -silent'' to test)

==Using the crontab program on Unix/Linux==

Once you have selected (and tested!) an appropriate command to invoke the Moodle cron it must be added to the web users 'crontab' to schedule it to run regularly. 'Crontab' is both a file containing the user's cron commands and is also the name of the (command line) program used to edit it. Use the following command (as root) substituting the correct user in place of 'www-data' (e.g. 'apache' for Centos, 'www-data' for Debian/Ubuntu, '_www' for macOS—Google will know!)
<pre>
# crontab -u www-data -e
</pre>
This will bring up an editor window (the first time it may ask you which editor to use). Add the command onto the end of the file in this way (it may be empty or it may have some instructional comments):
<pre>
*/1 * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
The first five entries specify the times, followed by the command, to run. This says to run the command every minute which is normally ok. On a hosted system you may get complaints if you do not run it a lot less often (e.g. to run every two hours use '0 */2 * * *' for the first five entries). If you want to use the wget/curl version, the first five entries remain the same - just change the command part.

== Low latency adhoc tasks ==

Each time cron is run, after the scheduled tasks the adhoc tasks are also run. While scheduled tasks can run at most once a minute, adhoc tasks can be queued at any moment, and generally you want them processed as soon as possible and to not have to wait for the scheduled task to run first. If you only run the normal admin/cli/cron.php then not only might it have to wait to process all the scheduled tasks first, if it has already finished you will have to wait until the next minute for cron to start again for it to be processed.

Instead you can run one or more dedicated adhoc task processors which run in parallel to the main cron process.

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...
</pre>

Starting from Moodle 3.9 the --keep-alive option runs like a daemon so when the queue is empty rather then exiting it waits for new tasks to be queued so it can start processing as soon as possible.

== Scaling up cron with multiple processes ==

As your site grows many of the scheduled tasks will take longer to complete, and also there will be more adhoc tasks queued which need to be processed. The cron system is designed to work in parallel but each individual process can only process one task at a time so you must run multiple cron cli's. You can generally run a fairly high number of cron processes on a dedicated cron instance before needing to run multiple cron instances. To run more than one process simply spawn multiple cron processes each minute:

<code>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
...
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...
</code>

It can be especially important to increase the number of adhoc_task.php processes as certain plugins and systems can generate very large numbers of adhoc tasks, or tasks that can take a long time to process. Especially tasks like document conversions and automated backups can build up more quickly than they are processed if they are left on default settings.

By default only 3 scheduled tasks and 3 adhoc tasks can be run concurrently so as you add more processes you need to increase the level of allowed concurrency:

Site administration > Server > Tasks > Task processing

<code php>
config.php:
$CFG->task_scheduled_concurrency_limit = 20; // Defaults to 3
$CFG->task_adhoc_concurrency_limit = 50; // Defaults to 3
</code>

Whatever you set these too make sure the server(s) hosting them can comfortably handle this many processes. Often the bottleneck will be a shared service, usually the database.

You may find that certain types of very long running tasks will consume all the available task runners which means no other tasks will run. eg if you have 5 cli processes, but in the task queue there are 20 adhoc tasks for an automated backup, each of which will take ten minutes to complete, then very quickly all 5 processes will be consumed by backups and nothing else. Other small very fast and light tasks like a document conversion or forum emails will not get sent until the backups are complete and a runner frees up. To manage this you can limit the concurrency of specific types of adhoc tasks. A good rule of thumb is that if all of the 'heavy' tasks consume all of their own limits then you should still have another few processes standing by on idle waiting for anything else which may be added to the queue.

<code php>
config.php:
$CFG->task_concurrency_limit = [
'core\task\course_backup_task' => 28,
'core_course\task\course_delete_modules' => 6,
];
</code>

== See also ==

* [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]
* [http://www.easycron.com/predictor Predicting Cron job's run time]

[[es:Cron con Unix o Linux]]

Cron with Unix or Linux

2021-01-28T10:19:43Z

Brendanheywood: /* Scaling up cron with multiple processes */

{{Installing Moodle}}
On Unix and Linux use the built in ''cron'' program which is standard on nearly all systems. You are required to add a command to the 'crontab' (the table that holds cron commands) for the web server user.

There are two different methods that can be used to invoke the Moodle cron process:

'''NOTE:''' The commands shown need to be added to the crontab to function (described in a moment). However, you can - and should - run them on the command line to check they work first.

== Method 1: The command line (cli) cron ==

If you have a choice, this is normally the best way to run Moodle cron.

PHP is also capable of running programs directly from the command line. Your system needs to be set up to do this; specifically you need the 'CLI' version of PHP to be installed. Most systems with PHP installed will have this by default. If you have the PHP CLI version installed then this is the recommended method of invoking cron. The correct command will be something like...
<pre>
/usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
(substitute the correct path to moodle and for php as required)

You can simply type this on the command line this to see if it works. If you are not sure about the path to PHP you can type "<code>which php</code>".

'''Tip:''': If you have problems, see the [[PHP]] page. In particular, suspect an alternate php.ini for the CLI PHP command which may not have suitable settings.

== Method 2: Web based cron ==

'''NOTE:''' In order to use the web based cron script you must first check [[Cron settings]] to make sure this method is permitted.

The idea is to call the following web page (you can try this from your browser):
<pre>
http://url.of.your/moodle/admin/cron.php
</pre>

A command line (text based) browser is needed to run this on the server. Possibilities are as follows (OSX, for example, only ships with curl)...
<pre>
/usr/bin/wget -q -O /dev/null/ http://url.of.your/moodle/admin/cron.php
</pre>
(no output is displayed - remove the ''-O /dev/null/'' to test)

...OR...

<pre>
/usr/bin/curl http://url.of.your/moodle/admin/cron.php -o /dev/null/ -silent
</pre>
(no output is displayed - remove the ''-o /dev/null/ -silent'' to test)

==Using the crontab program on Unix/Linux==

Once you have selected (and tested!) an appropriate command to invoke the Moodle cron it must be added to the web users 'crontab' to schedule it to run regularly. 'Crontab' is both a file containing the user's cron commands and is also the name of the (command line) program used to edit it. Use the following command (as root) substituting the correct user in place of 'www-data' (e.g. 'apache' for Centos, 'www-data' for Debian/Ubuntu, '_www' for macOS—Google will know!)
<pre>
# crontab -u www-data -e
</pre>
This will bring up an editor window (the first time it may ask you which editor to use). Add the command onto the end of the file in this way (it may be empty or it may have some instructional comments):
<pre>
*/1 * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
</pre>
The first five entries specify the times, followed by the command, to run. This says to run the command every minute which is normally ok. On a hosted system you may get complaints if you do not run it a lot less often (e.g. to run every two hours use '0 */2 * * *' for the first five entries). If you want to use the wget/curl version, the first five entries remain the same - just change the command part.

== Low latency adhoc tasks ==

Each time cron is run, after the scheduled tasks the adhoc tasks are also run. While scheduled tasks can run at most once a minute, adhoc tasks can be queued at any moment, and generally you want them processed as soon as possible and to not have to wait for the scheduled task to run first. If you only run the normal admin/cli/cron.php then not only might it have to wait to process all the scheduled tasks first, if it has already finished you will have to wait until the next minute for cron to start again for it to be processed.

Instead you can run one or more dedicated adhoc task processors which run in parallel to the main cron process.

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
...
</pre>

Starting from Moodle 3.9 the --keep-alive option runs like a daemon so when the queue is empty rather then exiting it waits for new tasks to be queued so it can start processing as soon as possible.

== Scaling up cron with multiple processes ==

As your site grows many of the scheduled tasks will take longer to complete, and also there will be more adhoc tasks queued which need to be processed. The cron system is designed to work in parallel but each individual process can only process one task at a time so you must run multiple cron cli's. You can generally run a fairly high number of cron processes on a dedicated cron instance before needing to run multiple cron instances. To run more than one process simply spawn multiple cron processes each minute:

<code>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
...
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...
</code>

It can be especially important to increase the number of adhoc_task.php processes as certain plugins and systems can generate very large numbers of adhoc tasks, or tasks that can take a long time to process. Especially tasks like document conversions and automated backups can build up more quickly than they are processed if they are left on default settings.

By default only 3 scheduled tasks and 3 adhoc tasks can be run concurrently so as you add more processes you need to increase the level of allowed concurrency:

Site administration > Server > Tasks > Task processing

<code php>
config.php:
$CFG->task_scheduled_concurrency_limit = 20; // Defaults to 3
$CFG->task_adhoc_concurrency_limit = 50; // Defaults to 3
</code>

Whatever you set these too make sure the server(s) hosting them can comfortably handle this many processes. Often the bottleneck will be a shared service, usually the database.

You may find that certain types of very long running tasks will consume all the available task runners which means no other tasks will run. eg if you have 5 cli processes, but in the task queue there are 20 adhoc tasks for an automated backup, each of which will take ten minutes to complete, then very quickly all 5 processes will be consumed by backups and nothing else. Other small very fast and light tasks like a document conversion or forum emails will not get sent until the backups are complete and a runner frees up. To manage this you can limit the concurrency of specific types of adhoc tasks. A good rule of thumb is that if all of the 'heavy' tasks consume all of their own limits then you should still have another few processes standing by on idle waiting for anything else which may be added to the queue.

<code php>
config.php:
$CFG->task_concurrency_limit = [
'core\task\course_backup_task' => 28,
'core_course\task\course_delete_modules' => 6,
];
</code>

== See also ==

* [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]
* [http://www.easycron.com/predictor Predicting Cron job's run time]

[[es:Cron con Unix o Linux]]

Cron with Unix or Linux

2021-01-28T10:14:54Z

Brendanheywood: /* Scaling up cron with multiple processes */

{{Installing Moodle}}
On Unix and Linux use the built in ''cron'' program which is standard on nearly all systems. You are required to add a command to the 'crontab' (the table that holds cron commands) for the web server user.

There are two different methods that can be used to invoke the Moodle cron process:

'''NOTE:''' The commands shown need to be added to the crontab to function (described in a moment). However, you can - and should - run them on the command line to check they work first.

== Method 1: The command line (cli) cron ==

If you have a choice, this is normally the best way to run Moodle cron.

PHP is also capable of running programs directly from the command line. Your system needs to be set up to do this; specifically you need the 'CLI' version of PHP to be installed. Most systems with PHP installed will have this by default. If you have the PHP CLI version installed then this is the recommended method of invoking cron. The correct command will be something like...
<pre>
/usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
(substitute the correct path to moodle and for php as required)

You can simply type this on the command line this to see if it works. If you are not sure about the path to PHP you can type "<code>which php</code>".

'''Tip:''': If you have problems, see the [[PHP]] page. In particular, suspect an alternate php.ini for the CLI PHP command which may not have suitable settings.

== Method 2: Web based cron ==

'''NOTE:''' In order to use the web based cron script you must first check [[Cron settings]] to make sure this method is permitted.

The idea is to call the following web page (you can try this from your browser):
<pre>
http://url.of.your/moodle/admin/cron.php
</pre>

A command line (text based) browser is needed to run this on the server. Possibilities are as follows (OSX, for example, only ships with curl)...
<pre>
/usr/bin/wget -q -O /dev/null/ http://url.of.your/moodle/admin/cron.php
</pre>
(no output is displayed - remove the ''-O /dev/null/'' to test)

...OR...

<pre>
/usr/bin/curl http://url.of.your/moodle/admin/cron.php -o /dev/null/ -silent
</pre>
(no output is displayed - remove the ''-o /dev/null/ -silent'' to test)

==Using the crontab program on Unix/Linux==

Once you have selected (and tested!) an appropriate command to invoke the Moodle cron it must be added to the web users 'crontab' to schedule it to run regularly. 'Crontab' is both a file containing the user's cron commands and is also the name of the (command line) program used to edit it. Use the following command (as root) substituting the correct user in place of 'www-data' (e.g. 'apache' for Centos, 'www-data' for Debian/Ubuntu, '_www' for macOS—Google will know!)
<pre>
# crontab -u www-data -e
</pre>
This will bring up an editor window (the first time it may ask you which editor to use). Add the command onto the end of the file in this way (it may be empty or it may have some instructional comments):
<pre>
*/1 * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
</pre>
The first five entries specify the times, followed by the command, to run. This says to run the command every minute which is normally ok. On a hosted system you may get complaints if you do not run it a lot less often (e.g. to run every two hours use '0 */2 * * *' for the first five entries). If you want to use the wget/curl version, the first five entries remain the same - just change the command part.

== Low latency adhoc tasks ==

Each time cron is run, after the scheduled tasks the adhoc tasks are also run. While scheduled tasks can run at most once a minute, adhoc tasks can be queued at any moment, and generally you want them processed as soon as possible and to not have to wait for the scheduled task to run first. If you only run the normal admin/cli/cron.php then not only might it have to wait to process all the scheduled tasks first, if it has already finished you will have to wait until the next minute for cron to start again for it to be processed.

Instead you can run one or more dedicated adhoc task processors which run in parallel to the main cron process.

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
...
</pre>

Starting from Moodle 3.9 the --keep-alive option runs like a daemon so when the queue is empty rather then exiting it waits for new tasks to be queued so it can start processing as soon as possible.

== Scaling up cron with multiple processes ==

As your site grows many of the scheduled tasks will take longer to complete, and also there will be more adhoc tasks queued which need to be processed. The cron system is designed to work in parallel but each individual process can only process one task at a time so you must run multiple cron cli's. You can generally run a fairly high number of cron processes on a dedicated cron instance before needing to run multiple cron instances. To run more than one process simply spawn multiple cron processes each minute:

<code>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
...
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
...
</code>

It can be especially important to increase the number of adhoc_task.php processes as certain plugins and systems can generate very large numbers of adhoc tasks, or tasks that can take a long time to process. Especially tasks like document conversions and automated backups can build up more quickly than they are processed if they are left on default settings.

By default only 3 scheduled tasks and 3 adhoc tasks can be run concurrently so as you add more processes you need to increase the level of allowed concurrency:

Site administration > Server > Tasks > Task processing

<code php>
config.php:
$CFG->task_scheduled_concurrency_limit = 20; // Defaults to 3
$CFG->task_adhoc_concurrency_limit = 50; // Defaults to 3
</code>

Whatever you set these too make sure the server(s) hosting them can comfortably handle this many processes. Often the bottleneck will be a shared service, usually the database.

You may find that certain types of very long running tasks will consume all the available task runners which means no other tasks will run. eg if you have 5 cli processes, but in the task queue there are 20 adhoc tasks for an automated backup, each of which will take ten minutes to complete, then very quickly all 5 processes will be consumed by backups and nothing else. Other small very fast and light tasks like a document conversion or forum emails will not get sent until the backups are complete and a runner frees up. To manage this you can limit the concurrency of specific types of adhoc tasks. A good rule of thumb is that if all of the 'heavy' tasks consume all of their own limits then you should still have another few processes standing by on idle waiting for anything else which may be added to the queue.

<code php>
config.php:
$CFG->task_concurrency_limit = [
'core\task\course_backup_task' => 28,
'core_course\task\course_delete_modules' => 6,
];
</code>

== See also ==

* [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]
* [http://www.easycron.com/predictor Predicting Cron job's run time]

[[es:Cron con Unix o Linux]]

Cron with Unix or Linux

2021-01-28T10:14:08Z

Brendanheywood: /* High performance cron tasks */

{{Installing Moodle}}
On Unix and Linux use the built in ''cron'' program which is standard on nearly all systems. You are required to add a command to the 'crontab' (the table that holds cron commands) for the web server user.

There are two different methods that can be used to invoke the Moodle cron process:

'''NOTE:''' The commands shown need to be added to the crontab to function (described in a moment). However, you can - and should - run them on the command line to check they work first.

== Method 1: The command line (cli) cron ==

If you have a choice, this is normally the best way to run Moodle cron.

PHP is also capable of running programs directly from the command line. Your system needs to be set up to do this; specifically you need the 'CLI' version of PHP to be installed. Most systems with PHP installed will have this by default. If you have the PHP CLI version installed then this is the recommended method of invoking cron. The correct command will be something like...
<pre>
/usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
(substitute the correct path to moodle and for php as required)

You can simply type this on the command line this to see if it works. If you are not sure about the path to PHP you can type "<code>which php</code>".

'''Tip:''': If you have problems, see the [[PHP]] page. In particular, suspect an alternate php.ini for the CLI PHP command which may not have suitable settings.

== Method 2: Web based cron ==

'''NOTE:''' In order to use the web based cron script you must first check [[Cron settings]] to make sure this method is permitted.

The idea is to call the following web page (you can try this from your browser):
<pre>
http://url.of.your/moodle/admin/cron.php
</pre>

A command line (text based) browser is needed to run this on the server. Possibilities are as follows (OSX, for example, only ships with curl)...
<pre>
/usr/bin/wget -q -O /dev/null/ http://url.of.your/moodle/admin/cron.php
</pre>
(no output is displayed - remove the ''-O /dev/null/'' to test)

...OR...

<pre>
/usr/bin/curl http://url.of.your/moodle/admin/cron.php -o /dev/null/ -silent
</pre>
(no output is displayed - remove the ''-o /dev/null/ -silent'' to test)

==Using the crontab program on Unix/Linux==

Once you have selected (and tested!) an appropriate command to invoke the Moodle cron it must be added to the web users 'crontab' to schedule it to run regularly. 'Crontab' is both a file containing the user's cron commands and is also the name of the (command line) program used to edit it. Use the following command (as root) substituting the correct user in place of 'www-data' (e.g. 'apache' for Centos, 'www-data' for Debian/Ubuntu, '_www' for macOS—Google will know!)
<pre>
# crontab -u www-data -e
</pre>
This will bring up an editor window (the first time it may ask you which editor to use). Add the command onto the end of the file in this way (it may be empty or it may have some instructional comments):
<pre>
*/1 * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
</pre>
The first five entries specify the times, followed by the command, to run. This says to run the command every minute which is normally ok. On a hosted system you may get complaints if you do not run it a lot less often (e.g. to run every two hours use '0 */2 * * *' for the first five entries). If you want to use the wget/curl version, the first five entries remain the same - just change the command part.

== Low latency adhoc tasks ==

Each time cron is run, after the scheduled tasks the adhoc tasks are also run. While scheduled tasks can run at most once a minute, adhoc tasks can be queued at any moment, and generally you want them processed as soon as possible and to not have to wait for the scheduled task to run first. If you only run the normal admin/cli/cron.php then not only might it have to wait to process all the scheduled tasks first, if it has already finished you will have to wait until the next minute for cron to start again for it to be processed.

Instead you can run one or more dedicated adhoc task processors which run in parallel to the main cron process.

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
...
</pre>

Starting from Moodle 3.9 the --keep-alive option runs like a daemon so when the queue is empty rather then exiting it waits for new tasks to be queued so it can start processing as soon as possible.

== Scaling up cron with multiple processes ==

As your site grows many of the scheduled tasks will take longer to complete, and also there will be more adhoc tasks queued which need to be processed. The cron system is designed to work in parallel but each individual process can only process one task at a time so you must run multiple cron cli's. You can generally run a fairly high number of cron processes on a dedicated cron instance before needing to run multiple cron instances. To run more than one process simply spawn multiple cron processes each minute:

<code>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
...
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
...
</code>

It can be especially important to increase the number of adhoc_task.php processes as certain plugins and systems can generate very large numbers of adhoc tasks, or tasks that can take a long time to process. Especially tasks like document conversions and automated backups can build up more quickly than they are processed if they are left on default settings.

By default only 3 scheduled tasks and 3 adhoc tasks can be run concurrently so as you add more processes you need to increase the level of allowed concurrency:

<code php>
config.php:
$CFG->task_scheduled_concurrency_limit = 20; // Defaults to 3
$CFG->task_adhoc_concurrency_limit = 50; // Defaults to 3
</code>

Whatever you set these too make sure the server(s) hosting them can comfortably handle this many processes. Often the bottleneck will be a shared service, usually the database.

You may find that certain types of very long running tasks will consume all the available task runners which means no other tasks will run. eg if you have 5 cli processes, but in the task queue there are 20 adhoc tasks for an automated backup, each of which will take ten minutes to complete, then very quickly all 5 processes will be consumed by backups and nothing else. Other small very fast and light tasks like a document conversion or forum emails will not get sent until the backups are complete and a runner frees up. To manage this you can limit the concurrency of specific types of adhoc tasks. A good rule of thumb is that if all of the 'heavy' tasks consume all of their own limits then you should still have another few processes standing by on idle waiting for anything else which may be added to the queue.

<code php>
config.php:
$CFG->task_concurrency_limit = [
'core\task\course_backup_task' => 28,
'core_course\task\course_delete_modules' => 6,
];
</code>

== See also ==

* [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]
* [http://www.easycron.com/predictor Predicting Cron job's run time]

[[es:Cron con Unix o Linux]]

Cron with Unix or Linux

2021-01-28T10:08:18Z

Brendanheywood: /* Scaling up cron with multiple processes */

{{Installing Moodle}}
On Unix and Linux use the built in ''cron'' program which is standard on nearly all systems. You are required to add a command to the 'crontab' (the table that holds cron commands) for the web server user.

There are two different methods that can be used to invoke the Moodle cron process:

'''NOTE:''' The commands shown need to be added to the crontab to function (described in a moment). However, you can - and should - run them on the command line to check they work first.

== Method 1: The command line (cli) cron ==

If you have a choice, this is normally the best way to run Moodle cron.

PHP is also capable of running programs directly from the command line. Your system needs to be set up to do this; specifically you need the 'CLI' version of PHP to be installed. Most systems with PHP installed will have this by default. If you have the PHP CLI version installed then this is the recommended method of invoking cron. The correct command will be something like...
<pre>
/usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
(substitute the correct path to moodle and for php as required)

You can simply type this on the command line this to see if it works. If you are not sure about the path to PHP you can type "<code>which php</code>".

'''Tip:''': If you have problems, see the [[PHP]] page. In particular, suspect an alternate php.ini for the CLI PHP command which may not have suitable settings.

== Method 2: Web based cron ==

'''NOTE:''' In order to use the web based cron script you must first check [[Cron settings]] to make sure this method is permitted.

The idea is to call the following web page (you can try this from your browser):
<pre>
http://url.of.your/moodle/admin/cron.php
</pre>

A command line (text based) browser is needed to run this on the server. Possibilities are as follows (OSX, for example, only ships with curl)...
<pre>
/usr/bin/wget -q -O /dev/null/ http://url.of.your/moodle/admin/cron.php
</pre>
(no output is displayed - remove the ''-O /dev/null/'' to test)

...OR...

<pre>
/usr/bin/curl http://url.of.your/moodle/admin/cron.php -o /dev/null/ -silent
</pre>
(no output is displayed - remove the ''-o /dev/null/ -silent'' to test)

==Using the crontab program on Unix/Linux==

Once you have selected (and tested!) an appropriate command to invoke the Moodle cron it must be added to the web users 'crontab' to schedule it to run regularly. 'Crontab' is both a file containing the user's cron commands and is also the name of the (command line) program used to edit it. Use the following command (as root) substituting the correct user in place of 'www-data' (e.g. 'apache' for Centos, 'www-data' for Debian/Ubuntu, '_www' for macOS—Google will know!)
<pre>
# crontab -u www-data -e
</pre>
This will bring up an editor window (the first time it may ask you which editor to use). Add the command onto the end of the file in this way (it may be empty or it may have some instructional comments):
<pre>
*/1 * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
</pre>
The first five entries specify the times, followed by the command, to run. This says to run the command every minute which is normally ok. On a hosted system you may get complaints if you do not run it a lot less often (e.g. to run every two hours use '0 */2 * * *' for the first five entries). If you want to use the wget/curl version, the first five entries remain the same - just change the command part.

== High performance cron tasks ==

Each time cron is run, after the scheduled tasks the adhoc tasks are also run. But adhoc tasks can be queued at any moment, and generally you want them processed as soon as possible and to not have to wait for the scheduled task to run first. You can run one or more dedicated adhoc task processors:

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute >/dev/null
</pre>

Starting from Moodle 3.9 you can tell it to stay alive when the queue is empty waiting for new tasks:

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
</pre>

If you have a very high low number of adhoc tasks, or scheduled tasks, you can also spawn multiple cron.php and adhoc_task.php processes to get more throughput. By default Moodle will make sure than no more than 3 processes run at any time, you can tune these limits as needed in Site administration > Server > Tasks > Task processing

== Scaling up cron with multiple processes ==

As your site grows many of the scheduled tasks will take longer to complete, and also there will be more adhoc tasks queued which need to be processed. The cron system is designed to work in parallel but each individual process can only process one task at a time so you must run multiple cron cli's. You can generally run a fairly high number of cron processes on a dedicated cron instance before needing to run multiple cron instances. To run more than one process simply spawn multiple cron processes each minute:

<code>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
...
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
...
</code>

It can be especially important to increase the number of adhoc_task.php processes as certain plugins and systems can generate very large numbers of adhoc tasks, or tasks that can take a long time to process. Especially tasks like document conversions and automated backups can build up more quickly than they are processed if they are left on default settings.

By default only 3 scheduled tasks and 3 adhoc tasks can be run concurrently so as you add more processes you need to increase the level of allowed concurrency:

<code php>
config.php:
$CFG->task_scheduled_concurrency_limit = 20; // Defaults to 3
$CFG->task_adhoc_concurrency_limit = 50; // Defaults to 3
</code>

Whatever you set these too make sure the server(s) hosting them can comfortably handle this many processes. Often the bottleneck will be a shared service, usually the database.

You may find that certain types of very long running tasks will consume all the available task runners which means no other tasks will run. eg if you have 5 cli processes, but in the task queue there are 20 adhoc tasks for an automated backup, each of which will take ten minutes to complete, then very quickly all 5 processes will be consumed by backups and nothing else. Other small very fast and light tasks like a document conversion or forum emails will not get sent until the backups are complete and a runner frees up. To manage this you can limit the concurrency of specific types of adhoc tasks. A good rule of thumb is that if all of the 'heavy' tasks consume all of their own limits then you should still have another few processes standing by on idle waiting for anything else which may be added to the queue.

<code php>
config.php:
$CFG->task_concurrency_limit = [
'core\task\course_backup_task' => 28,
'core_course\task\course_delete_modules' => 6,
];
</code>

== See also ==

* [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]
* [http://www.easycron.com/predictor Predicting Cron job's run time]

[[es:Cron con Unix o Linux]]

Cron with Unix or Linux

2021-01-28T10:06:59Z

Brendanheywood: /* Scaling up cron with multiple processes */

{{Installing Moodle}}
On Unix and Linux use the built in ''cron'' program which is standard on nearly all systems. You are required to add a command to the 'crontab' (the table that holds cron commands) for the web server user.

There are two different methods that can be used to invoke the Moodle cron process:

'''NOTE:''' The commands shown need to be added to the crontab to function (described in a moment). However, you can - and should - run them on the command line to check they work first.

== Method 1: The command line (cli) cron ==

If you have a choice, this is normally the best way to run Moodle cron.

PHP is also capable of running programs directly from the command line. Your system needs to be set up to do this; specifically you need the 'CLI' version of PHP to be installed. Most systems with PHP installed will have this by default. If you have the PHP CLI version installed then this is the recommended method of invoking cron. The correct command will be something like...
<pre>
/usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
(substitute the correct path to moodle and for php as required)

You can simply type this on the command line this to see if it works. If you are not sure about the path to PHP you can type "<code>which php</code>".

'''Tip:''': If you have problems, see the [[PHP]] page. In particular, suspect an alternate php.ini for the CLI PHP command which may not have suitable settings.

== Method 2: Web based cron ==

'''NOTE:''' In order to use the web based cron script you must first check [[Cron settings]] to make sure this method is permitted.

The idea is to call the following web page (you can try this from your browser):
<pre>
http://url.of.your/moodle/admin/cron.php
</pre>

A command line (text based) browser is needed to run this on the server. Possibilities are as follows (OSX, for example, only ships with curl)...
<pre>
/usr/bin/wget -q -O /dev/null/ http://url.of.your/moodle/admin/cron.php
</pre>
(no output is displayed - remove the ''-O /dev/null/'' to test)

...OR...

<pre>
/usr/bin/curl http://url.of.your/moodle/admin/cron.php -o /dev/null/ -silent
</pre>
(no output is displayed - remove the ''-o /dev/null/ -silent'' to test)

==Using the crontab program on Unix/Linux==

Once you have selected (and tested!) an appropriate command to invoke the Moodle cron it must be added to the web users 'crontab' to schedule it to run regularly. 'Crontab' is both a file containing the user's cron commands and is also the name of the (command line) program used to edit it. Use the following command (as root) substituting the correct user in place of 'www-data' (e.g. 'apache' for Centos, 'www-data' for Debian/Ubuntu, '_www' for macOS—Google will know!)
<pre>
# crontab -u www-data -e
</pre>
This will bring up an editor window (the first time it may ask you which editor to use). Add the command onto the end of the file in this way (it may be empty or it may have some instructional comments):
<pre>
*/1 * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
</pre>
The first five entries specify the times, followed by the command, to run. This says to run the command every minute which is normally ok. On a hosted system you may get complaints if you do not run it a lot less often (e.g. to run every two hours use '0 */2 * * *' for the first five entries). If you want to use the wget/curl version, the first five entries remain the same - just change the command part.

== High performance cron tasks ==

Each time cron is run, after the scheduled tasks the adhoc tasks are also run. But adhoc tasks can be queued at any moment, and generally you want them processed as soon as possible and to not have to wait for the scheduled task to run first. You can run one or more dedicated adhoc task processors:

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute >/dev/null
</pre>

Starting from Moodle 3.9 you can tell it to stay alive when the queue is empty waiting for new tasks:

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
</pre>

If you have a very high low number of adhoc tasks, or scheduled tasks, you can also spawn multiple cron.php and adhoc_task.php processes to get more throughput. By default Moodle will make sure than no more than 3 processes run at any time, you can tune these limits as needed in Site administration > Server > Tasks > Task processing

== Scaling up cron with multiple processes ==

As your site grows many of the schedules tasks will take longer to complete, and also there will be more adhoc tasks queued which need to be processed. The cron system is designed to work in parallel but each individual process can only process one task at a time so you must run multiple cron cli's. You can generally run a fairly high number of cron processes on a dedicated cron instance before needing to run multiple cron instances. To run more than one process simply spawn multiple cron processes each minute:

<code>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
...
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
...
</code>

It can be especially important to increase the number of adhoc_task.php processes as certain plugins and systems can generate very large numbers of adhoc tasks, or tasks that can take a long time to process. Especially tasks like document conversions and automated backups can build up more quickly than they are processed if they are left on default settings.

By default only 3 scheduled tasks and 3 adhoc tasks can be run concurrently so as you add more processes you need to increase the level of allowed concurrency:

<code php>
config.php:
$CFG->task_scheduled_concurrency_limit = 20; // Defaults to 3
$CFG->task_adhoc_concurrency_limit = 50; // Defaults to 3
</code>

Whatever you set these too make sure the server(s) hosting them can comfortably handle this many processes. Often the bottleneck will be a shared service, usually the database.

You may find that certain types of very long running tasks will consume all the available task runners which means no other tasks will run. eg if you have 5 cli processes, but in the task queue there are 20 adhoc tasks for an automated backup, each of which will take ten minutes to complete, then very quickly all 5 processes will be consumed by backups and nothing else. Other small very fast and light tasks like a document conversion or forum emails will not get sent until the backups are complete and a runner frees up. To manage this you can limit the concurrency of specific types of adhoc tasks. A good rule of thumb is that if all of the 'heavy' tasks consume all of their own limits then you should still have another few processes standing by on idle waiting for anything else which may be added to the queue.

<code php>
config.php:
$CFG->task_concurrency_limit = [
'core\task\course_backup_task' => 28,
'core_course\task\course_delete_modules' => 6,
];
</code>

== See also ==

* [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]
* [http://www.easycron.com/predictor Predicting Cron job's run time]

[[es:Cron con Unix o Linux]]

Cron with Unix or Linux

2021-01-28T10:05:56Z

Brendanheywood: /* Scaling up cron and task runners */

{{Installing Moodle}}
On Unix and Linux use the built in ''cron'' program which is standard on nearly all systems. You are required to add a command to the 'crontab' (the table that holds cron commands) for the web server user.

There are two different methods that can be used to invoke the Moodle cron process:

'''NOTE:''' The commands shown need to be added to the crontab to function (described in a moment). However, you can - and should - run them on the command line to check they work first.

== Method 1: The command line (cli) cron ==

If you have a choice, this is normally the best way to run Moodle cron.

PHP is also capable of running programs directly from the command line. Your system needs to be set up to do this; specifically you need the 'CLI' version of PHP to be installed. Most systems with PHP installed will have this by default. If you have the PHP CLI version installed then this is the recommended method of invoking cron. The correct command will be something like...
<pre>
/usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
(substitute the correct path to moodle and for php as required)

You can simply type this on the command line this to see if it works. If you are not sure about the path to PHP you can type "<code>which php</code>".

'''Tip:''': If you have problems, see the [[PHP]] page. In particular, suspect an alternate php.ini for the CLI PHP command which may not have suitable settings.

== Method 2: Web based cron ==

'''NOTE:''' In order to use the web based cron script you must first check [[Cron settings]] to make sure this method is permitted.

The idea is to call the following web page (you can try this from your browser):
<pre>
http://url.of.your/moodle/admin/cron.php
</pre>

A command line (text based) browser is needed to run this on the server. Possibilities are as follows (OSX, for example, only ships with curl)...
<pre>
/usr/bin/wget -q -O /dev/null/ http://url.of.your/moodle/admin/cron.php
</pre>
(no output is displayed - remove the ''-O /dev/null/'' to test)

...OR...

<pre>
/usr/bin/curl http://url.of.your/moodle/admin/cron.php -o /dev/null/ -silent
</pre>
(no output is displayed - remove the ''-o /dev/null/ -silent'' to test)

==Using the crontab program on Unix/Linux==

Once you have selected (and tested!) an appropriate command to invoke the Moodle cron it must be added to the web users 'crontab' to schedule it to run regularly. 'Crontab' is both a file containing the user's cron commands and is also the name of the (command line) program used to edit it. Use the following command (as root) substituting the correct user in place of 'www-data' (e.g. 'apache' for Centos, 'www-data' for Debian/Ubuntu, '_www' for macOS—Google will know!)
<pre>
# crontab -u www-data -e
</pre>
This will bring up an editor window (the first time it may ask you which editor to use). Add the command onto the end of the file in this way (it may be empty or it may have some instructional comments):
<pre>
*/1 * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
</pre>
The first five entries specify the times, followed by the command, to run. This says to run the command every minute which is normally ok. On a hosted system you may get complaints if you do not run it a lot less often (e.g. to run every two hours use '0 */2 * * *' for the first five entries). If you want to use the wget/curl version, the first five entries remain the same - just change the command part.

== High performance cron tasks ==

Each time cron is run, after the scheduled tasks the adhoc tasks are also run. But adhoc tasks can be queued at any moment, and generally you want them processed as soon as possible and to not have to wait for the scheduled task to run first. You can run one or more dedicated adhoc task processors:

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute >/dev/null
</pre>

Starting from Moodle 3.9 you can tell it to stay alive when the queue is empty waiting for new tasks:

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
</pre>

If you have a very high low number of adhoc tasks, or scheduled tasks, you can also spawn multiple cron.php and adhoc_task.php processes to get more throughput. By default Moodle will make sure than no more than 3 processes run at any time, you can tune these limits as needed in Site administration > Server > Tasks > Task processing

== Scaling up cron with multiple processes ==

As your site grows many of the schedules tasks will take longer to complete, and also there will be more adhoc tasks queued which need to be processed. The cron system is designed to work in parallel but each individual process can only process one task at a time so you must run multiple cron cli's. You can generally run a fairly high number of cron processes on a dedicated cron instance before needing to run multiple cron instances. To run more than one process simply spawn multiple cron processes each minute:

<code>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
...
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
...
</code>

It can be especially important to increase the number of adhoc_task.php processes as certain plugins and systems can generate very large numbers of adhoc tasks, or tasks that can take a long time to process.Especially tasks like document conversions and automated backups can build up more quickly than they are processed if they are left on default settings.

By default only 3 scheduled tasks and 3 adhoc tasks can be run concurrently so as you add more processes you need to increase the level of allowed concurrency:

<code php>
config.php:
$CFG->task_scheduled_concurrency_limit = 20; // Defaults to 3
$CFG->task_adhoc_concurrency_limit = 50; // Defaults to 3
</code>

Whatever you set these too make sure the server(s) hosting them can comfortably handle this many processes. Often the bottleneck will be a shared service, usually the database.

You may find that certain types of very long running tasks will consume all the available task runners which means no other tasks will run. eg if you have 5 cli processes, but in the task queue there are 20 adhoc tasks for an automated backup, each of which will take ten minutes to complete, then very quickly all 5 processes will be consumed by backups and nothing else. Other small very fast and light tasks like a document conversion or forum emails will not get sent until the backups are complete and a runner frees up. To manage this you can limit the concurrency of specific types of adhoc tasks. A good rule of thumb is that if all of the 'heavy' tasks consume all of their own limits then you should still have another few processes standing by on idle waiting for anything else which may be added to the queue.

<code php>
config.php:
$CFG->task_concurrency_limit = [
'core\task\course_backup_task' => 28,
'core_course\task\course_delete_modules' => 6,
];
</code>

== See also ==

* [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]
* [http://www.easycron.com/predictor Predicting Cron job's run time]

[[es:Cron con Unix o Linux]]

Cron with Unix or Linux

2021-01-28T07:59:27Z

Brendanheywood:

Cron with Unix or Linux

2021-01-28T07:58:50Z

Brendanheywood: /* High performance cron tasks */

Site security settings

2020-11-12T23:59:07Z

Brendanheywood: /* Open to Google */

.
{{Security}}
===Protect usernames===

If enabled, when a user attempts to reset their password and enters a username or email address, the following message is displayed: "If you supplied a correct username or email address then an email should have been sent to you." This is to prevent a malicious party from using the interface to determine which usernames and email addresses are in use in valid accounts.

If the protect usernames setting is disabled, when a user attempts to reset their password they are provided with feedback regarding whether an account exists with the username or email address supplied. For example, the message "The email address was not found in the database" may be displayed.

===Force users to login===

If you turn this setting on, all users must login before they even see the [[Front Page]] of the site. Note however that this does not prevent guest access to courses, if you have autologin guests enabled in [[User policies]].

===Force users to login for profiles===

Leave this set to Yes to keep anonymous visitors away from user profiles.

===Force users to login to view user pictures===

If enabled, users must login in order to view user profile pictures and the default user picture will be used in all notification emails.

===Open to Google===

Enabling this setting allows Google's search spiders guest access to your site. Any part of the site that allows guest access will then be searchable on Google. In addition, people coming in to your site via a Google search will automatically be logged in as a guest.

=== Referrer policy ===

A referrer policy can be set, various parts of moodle rely on the referrer being set so it's generally best to only remove or reduce the referrer for external links. So a policy of origin-when-cross-origin is probably the best balance.
See the MDN docs for more details:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

==Allow indexing by search engines==
This determines whether to allow search engines to index your site. The default is Everywhere except login and signup pages.

===Profile visible roles===
Any role which is checked/ticked here will be visible on user profiles and the Participation screen.

===Maximum uploaded file size===

Probably the most frequently asked question in the Moodle.org Using Moodle forums is "How do I increase the upload file size limit?"

Upload file sizes are restricted in a number of ways - each one in this list restricts the following ones:

1. The Apache server setting LimitRequestBody ... default in Apache 2.x or greater is set to 0 or an unlimited upload size

2. The PHP site settings post_max_size and upload_max_filesize in php.ini : '''modify php.ini in web server directories''' ( apache2.x.x/bin/php.ini ) not in php directories :

post_max_size = 128M; to increase limit to 128 Megabytes;
upload_max_filesize = 128M; to increase limit to 128 Megabytes;
max_execution_time = 600 ; Maximum execution time of each script, in seconds;

3. The Moodle site-wide maximum uploaded file size setting: ''Settings > Site administration > Security > Site policies > Maximum uploaded file size''.

4. The Moodle course maximum uploaded file size setting in the course default settings: ''Settings > Site administration > Courses > Course default settings''

5. The file size settings in each individual course in ''Course Administration>Settings''.

5. Certain course activity module settings (for example, Assignment)

* See [[File upload size]] for more details.

===User quota===

The maximum number of bytes that a user can store in their own [[Private files]] area.

===Allow EMBED and OBJECT tags===
Allowing these presents a security risk but if you wish normal users such as students to be able to use them then check the box here.

===Enable trusted content===

By default Moodle will always thoroughly clean text that comes from users to remove any possible bad scripts, media etc that could be a security risk. The Trusted Content system is a way of giving particular users that you trust the ability to include these advanced features in their content without interference. To enable this system, you need to first enable this setting, and then grant the [[Capabilities/moodle/site:trustcontent|Trust submitted content]] capability to a specific Moodle role. Texts created or uploaded by such users will be marked as trusted and will not be cleaned before display.

===Maximum time to edit posts===

This sets the editing time for forum postings. The editing time is the amount of time users have to change forum postings before they are mailed to subscribers.

Please refer to the forum discussions [http://moodle.org/mod/forum/discuss.php?d=28679 Editing a forum post after the 30 minutes deadline] and [http://moodle.org/mod/forum/discuss.php?d=5367 The philosophy underlying "no editing after 30 minutes"]

===Full name format===

This setting has been moved in Moodle 2.6 onwards to ''Administration > Site administration > Users > Permissions > [[Roles settings|User policies]]''.

===Allow extended characters in usernames===

The default here, unchecked = unenabled, can only contain alphabetical letters in lowercase, numbers, hypen '-', underscore '_', period '.', or at sign '@'. If you enable this, it will be possible to have any characters for the username, but they must still be lowercase. This setting would allow you for example to have usernames with accents such as ö or ê and so on.

Note: In Moodle 3.4.2 onwards, the Site policy URL and Site policy URL for guests settings have been moved to 'Policy settings' in the Site administration.

===Keep tag name casing===

If checked, then tags like the following will be displayed: SOCCER, gUiTaR, MacDonalds, music

If unchecked, then all tags will be displayed as follows: Soccer, Guitar, Macdonalds, Music

:''Tips'':
:* For English, off is useful.
:* For Japanese, no changes are made either way.
:* For languages where this kind of capitalization changes the meaning, it is best to keep this option on.

===Profiles for enrolled users only===

To prevent misuse by spammers, profile descriptions of users who are not yet enrolled in any course are hidden. New users must enrol in at least one course before they can add a profile description.

===Cron execution via command line only===

[[Cron]] is an action that runs various administrative jobs on your Moodle such as sending out forum posts. Running the cron from a web browser can expose privileged information to anonymous users. Thus it is recommended to only run the cron from the command line or set a cron password for remote access.

===Cron password for remote access===

Setting a password will mean that users can only run cron from the browser if they know the password and add it like this:
www.YOURMOODLE.com/admin/cron.php/?password=THEPASSWORDYOUSET.

===Account lockout===

Account lockout may be enabled.

Account lockout threshold: After a specified number of failed login attempts, a user's account is locked and they are sent an email containing a URL to unlock the account. Setting this to 'No' means there is no threshold and an account attempting to log in can do so an unlimited number of times.

Account lockout observation window: Observation time for lockout threshold, if there are no failed attempts the threshold counter is reset after this time. This is the counter for how long to watch for more failed attempts by an account trying to log in even after being locked out, the counter will reset at each attempt and last this long.

Account lockout duration: Locked out account is automatically unlocked after this duration.

The account may also be unlocked by an administrator in ''Administration > Site administration > Users > Accounts > Browse list of users'' or by waiting for the account lockout duration to elapse.

===Password policy===

It is highly recommended that a password policy is set to force users to use stronger passwords that are less susceptible to being cracked by a intruder.
[[Image:Password policy.png|thumb|Password policy]]

The password policy includes option to set the minimum length of the password, the minimum number of digits, the minimum number of lower-case characters, the minimum number of upper-case characters and the minimum number of non alphanumeric characters.

The password policy is enabled by default. Default (recommended) settings are:
* Password length - 8
* Digits - 1
* Lowercase letters - 1
* Uppercase letters - 1
* Non-alphanumeric characters - 1

If a user enters a password that does not meet the requirements, they are given an error message indicating the nature of the problem with the entered password.

Enabling the password policy does not affect existing users until they decide to or are required to change their password. An admin can force all users to change their password using the force password change option in [[Bulk user actions]].

:''Tip'': The password policy may also be applied to [[Enrolment key|enrolment keys]] by ticking the 'Use password policy' checkbox in the [[Self enrolment]] settings.

===Password rotation limit===

Here you can specify how often a user must change their password before they can re-use a previous password. Note that this might not work with some external authentication plugins.

===Log out after password change===

By default, users can change their password and remain logged in. Enabling this setting will log them out of existing sessions except the one in which they specify their new password. This setting only applies to users manually changing their password, not to bulk password changes.

===User created token duration===

A new setting in Moodle 3.4 onwards enables the duration of a web services token created by a user (for example via the mobile app) to be set. (Previously the duration was 3 months and this value could not be changed.)

===Group enrolment key policy===
If this is enabled then when a teacher sets a group enrolment key, they will have to set a key which follows the password policy set above. Note that the group enrolment key policy requires the password policy to be enabled.

===Disable user profile images===

Check/tick this box if you don't want your users to be able to change their [[User pictures|profile images]].

===Email change confirmation===

A confirmation step is required for users to change their email address unless the ''emailchangeconfirmation'' box is unchecked.

===Remember username===
If you want usernames to be stored during login then set this to "yes". This will store permanent cookies and in some countries may be considered a privacy issue if used without consent. From a UK point of view, see http://tracker.moodle.org/secure/attachment/24290/UK+Laws+Relating+to+Cookies-LUNS2011.pdf See also the Using Moodle forum discussion [http://moodle.org/mod/forum/discuss.php?d=201558 EU Cookie Law].

===Strict validation of required fields===
If enabled, users are prevented from entering a space or line break only in required fields in forms. (note: add more info)

==See also==
* [[Policies plugin]] - The Policies plugin provides a new user sign-on process, with ability to define multiple policies (site, privacy, third party), track user consents, and manage updates and versioning of the policies

[[es:Políticas del sitio]]
[[eu:Gunearen_politikak]]
[[fr:Règles site]]
[[ja:サイトポリシー]]
[[de:Sicherheitsregeln der Website]]

Session handling

2020-08-15T05:25:58Z

Brendanheywood: /* Redis session driver */

{{Server settings}}
An administrator can change the following settings in 'Session Handling' in the Site administration.

Once someone logs in to your Moodle server, the server starts a session. The session data allows the server to track users as they access different pages.

==Use database for session information==

Moodle needs to store the session data in some storage. By default either file or database session storage is selected, this option allows admin to change it. Large installation should use memcached driver described below.

Note that this option disappears after setting the $CFG->session_handler_class in config.php file.

==Timeout==

If users don't load a new page during the amount of time set here, Moodle will end their session and log them out.

Be sure this time frame is long enough to cover the longest test your teachers may offer. If a student is logged out while they are taking a test, their responses to the test questions may be lost.

==Cookie prefix==

Most of the time, you can leave this blank, unless you are running more than one Moodle site on the same server. In this case, you will want to customize the name of the cookie each Moodle site uses to track the session. This enables you to be logged into more than one Moodle site at the same time.

Note: If you change "Cookie prefix" or "Cookie path" you will need to login again as the changes take effect immediately.

==Cookie path==

The relative path to this Moodle installation, this may be used to force sending of Moodle session cookie to parent directories. Invalid values are ignored automatically.

==Cookie domain==

This can be used to send session cookies to higher domains instead of just the server domain. This may be useful for some SSO solutions. Invalid values are ignored automatically.

==Session drivers==
User sessions may be stored in different backends. Session drivers can be configured only in config.php file - see examples in config-dist.php file.

===Memcached session driver===
The Memcached session driver is the fastest driver. It requires external memcached server and memcached PHP extension. Server cluster nodes must use shared session storage.

Configuration options in config.php:
<code php>
$CFG->session_handler_class = '\core\session\memcached';
$CFG->session_memcached_save_path = '127.0.0.1:11211';
$CFG->session_memcached_prefix = 'memc.sess.key.';
$CFG->session_memcached_acquire_lock_timeout = 120;
$CFG->session_memcached_lock_expire = 7200; // Ignored if memcached extension <= 2.1.0
</code>

Notes:
* Make sure the memcached server has enough memory.
* Use different prefix when storing sessions from multiple Moodle sites in one server.
* If PECL memcached extension version installed is less that 2.2.0, the locking works differently from other drivers - the lock is expired/released at the end of timeout - see MDL-42485.
* '''Don't use the same memcached server for both sessions and MUC. Events triggering MUC caches to be purged leads to MUC purging the memcached server - thus terminating ALL sessions.'''
* The <code php>$CFG->session_memcached_number_of_replicas</code> option is no longer supported.

For windows users, PHP.net only supplies binaries for memcache, (and not memcached). (http://windows.php.net/downloads/pecl/releases/)

(As of 2.7, two different contribs exist for memcache session handling - see MDL-42011 - it seems the OU one doesn't use prefix/lock_expire for some reason... possibly better to use the catalyst patch, where the only difference to the above config.php is the spelling of memcache(d).)

===File session driver===
This driver is used by default in new installation.

Configuration options in config.php:
<code php>
$CFG->session_handler_class = '\core\session\file';
$CFG->session_file_save_path = $CFG->dataroot.'/sessions';
</code>

Notes:
* File based sessions require file system that supports file locking.

===Database session driver===
This type of driver was used by default in Moodle 2.0-2.5.

<code php>
$CFG->session_handler_class = '\core\session\database';
$CFG->session_database_acquire_lock_timeout = 120;
</code>

Notes:
* DB sessions are not compatible with MyISAM database engine.
* If you are using MySQL/MariaDB make sure that \'max_allowed_packet\' in my.cnf (or my.ini) is at least 4M.
* The performance is relatively low, it is not recommended for large sites.

===Redis session driver===

The [[Redis]] session driver is available in Moodle 3.1.3 onwards (see MDL-54606). It requires a [[Redis_cache_store#Installing_Redis_server|Redis server]] and the [[Redis_cache_store#Installing_Redis_php_driver|Redis extension]].

Configuration options in config.php:
<code php>
$CFG->session_handler_class = '\core\session\redis';
$CFG->session_redis_host = '127.0.0.1';
$CFG->session_redis_port = 6379; // Optional.
$CFG->session_redis_database = 0; // Optional, default is db 0.
$CFG->session_redis_auth = ''; // Optional, default is don't set one.
$CFG->session_redis_prefix = ''; // Optional, default is don't set one.
$CFG->session_redis_acquire_lock_timeout = 120;
$CFG->session_redis_acquire_lock_retry = 100; // Optional, default is 100ms (from 3.9)
$CFG->session_redis_lock_expire = 7200;
$CFG->session_redis_serializer_use_igbinary = false; // Optional, default is PHP builtin serializer.
</code>

Notes:
* Be careful on changing the default serializer: it requires <code php>--enable-redis-igbinary</code> at ''phpredis'' extension compile time '''and''' you need to remove '''the previous session data''' before using Moodle again.

== Read only sessions ==

There is an experimental feature in Moodle 3.9 allowing certain pages to start readonly sessions which do not require a write lock with the aim of high performance at scale.

https://tracker.moodle.org/browse/MDL-58018

Details TBA

==See also==
* [[Sessions FAQ]]

[[cs:admin/setting/sessionhandling]]
[[ja:セッションハンドリング]]
[[de:Sitzungsinformationen]]
[[es:Manejo de la sesión]]
[[fr:Gestion des sessions]]

Bulk enrolments

2020-05-14T03:57:15Z

Brendanheywood:

{{Infobox plugin
|type = local plugin
|entry = https://moodle.org/plugins/local_mass_enroll

maintainer = [[Rogier Van Dongen]]
|float = right
}}
Bulk enrolments allows you to enrol students and add them to groups in a Moodle course using an excel file containing the students' email address or userid.
Before you start, you will require an excel file containing a complete list of the students' email address or userids in the first column. Subsequent columns contain the names of any groups you want to add each student to.

NOTE: Not to be confused with this plugin with almost the same name:

https://moodle.org/plugins/local_bulkenrol

'''Create your CSV'''

In order to upload your students successfully, you will need to create a CSV file with the students details. CSVs are simple to create - one way is in a spreadsheet package, making sure to save it as a .csv file type.
At minimum, your CSV file should contain one column for the main student identifier, usually their email address but it can also be their userid, or student ID number.
Ensure you have column labels - this is because Moodle anticipates these and so ignores the first row of CSV file. In other words, don't put any actual student data in your file's top row. If you are using email then put 'email', if you are using user IDs then put 'userid'.
If you want to enrol the students into Groups, include a second column which gives the group name for each student. Be careful to type these exactly. Give it a column heading 'group'.
You can add subsequent groups in subsequent columns.

[[File:bulk_upload_csv.JPG]]

'''Enrol the Students'''

In the '''Settings''' block on your course, under '''Course administration''', click '''Users''' > '''Bulk enrolments'''.

Select '''Choose a file''' and upload your CSV file.
Make sure '''Role''' to assign is left as '''student'''.
Set '''First column contains''' to reflect they type of data you have used in your spreadsheet, either the students' email address, userid or ID number.
If you need to create groups, ensure '''Create group(s) if needed''' is set to Yes.
If you would like to create groupings in your course, based on the groups that the students will been placed into, ensure '''Create grouping(s) if needed''' is kept to yes. If you do not want to create groupings, set this to No.
To receive an email report confirming which students have been enrolled and which groups they have been placed into, keep '''Send me a mail report''' set to '''Yes'''.
Click '''Enrol them to my course'''.
Check the students have been enrolled in their groups by going to the '''Settings''' menu and under '''Course Administration''' click on '''Users''' then '''Groups'''.
You should see the groups listed, followed by the number of students in each group in brackets.
You can also bulk unenrol students from your course by clicking on Bulk unenrolments in the block, and following the instructions above.

[[File:bulk_upload.png]]

Session handling

2020-02-02T06:52:52Z

Brendanheywood: /* Read only sessions = */

{{Server settings}}
An administrator can change the following settings in 'Session Handling' in the Site administration.

Once someone logs in to your Moodle server, the server starts a session. The session data allows the server to track users as they access different pages.

==Use database for session information==

Moodle needs to store the session data in some storage. By default either file or database session storage is selected, this option allows admin to change it. Large installation should use memcached driver described below.

Note that this option disappears after setting the $CFG->session_handler_class in config.php file.

==Timeout==

If users don't load a new page during the amount of time set here, Moodle will end their session and log them out.

Be sure this time frame is long enough to cover the longest test your teachers may offer. If a student is logged out while they are taking a test, their responses to the test questions may be lost.

==Cookie prefix==

Most of the time, you can leave this blank, unless you are running more than one Moodle site on the same server. In this case, you will want to customize the name of the cookie each Moodle site uses to track the session. This enables you to be logged into more than one Moodle site at the same time.

Note: If you change "Cookie prefix" or "Cookie path" you will need to login again as the changes take effect immediately.

==Cookie path==

The relative path to this Moodle installation, this may be used to force sending of Moodle session cookie to parent directories. Invalid values are ignored automatically.

==Cookie domain==

This can be used to send session cookies to higher domains instead of just the server domain. This may be useful for some SSO solutions. Invalid values are ignored automatically.

==Session drivers==
User sessions may be stored in different backends. Session drivers can be configured only in config.php file - see examples in config-dist.php file.

===Memcached session driver===
The Memcached session driver is the fastest driver. It requires external memcached server and memcached PHP extension. Server cluster nodes must use shared session storage.

Configuration options in config.php:
<code php>
$CFG->session_handler_class = '\core\session\memcached';
$CFG->session_memcached_save_path = '127.0.0.1:11211';
$CFG->session_memcached_prefix = 'memc.sess.key.';
$CFG->session_memcached_acquire_lock_timeout = 120;
$CFG->session_memcached_lock_expire = 7200; // Ignored if memcached extension <= 2.1.0
</code>

Notes:
* Make sure the memcached server has enough memory.
* Use different prefix when storing sessions from multiple Moodle sites in one server.
* If PECL memcached extension version installed is less that 2.2.0, the locking works differently from other drivers - the lock is expired/released at the end of timeout - see MDL-42485.
* '''Don't use the same memcached server for both sessions and MUC. Events triggering MUC caches to be purged leads to MUC purging the memcached server - thus terminating ALL sessions.'''
* The <code php>$CFG->session_memcached_number_of_replicas</code> option is no longer supported.

For windows users, PHP.net only supplies binaries for memcache, (and not memcached). (http://windows.php.net/downloads/pecl/releases/)

(As of 2.7, two different contribs exist for memcache session handling - see MDL-42011 - it seems the OU one doesn't use prefix/lock_expire for some reason... possibly better to use the catalyst patch, where the only difference to the above config.php is the spelling of memcache(d).)

===File session driver===
This driver is used by default in new installation.

Configuration options in config.php:
<code php>
$CFG->session_handler_class = '\core\session\file';
$CFG->session_file_save_path = $CFG->dataroot.'/sessions';
</code>

Notes:
* File based sessions require file system that supports file locking.

===Database session driver===
This type of driver was used by default in Moodle 2.0-2.5.

<code php>
$CFG->session_handler_class = '\core\session\database';
$CFG->session_database_acquire_lock_timeout = 120;
</code>

Notes:
* DB sessions are not compatible with MyISAM database engine.
* If you are using MySQL/MariaDB make sure that \'max_allowed_packet\' in my.cnf (or my.ini) is at least 4M.
* The performance is relatively low, it is not recommended for large sites.

===Redis session driver===

The [[Redis]] session driver is available in Moodle 3.1.3 onwards (see MDL-54606). It requires a [[Redis_cache_store#Installing_Redis_server|Redis server]] and the [[Redis_cache_store#Installing_Redis_php_driver|Redis extension]].

Configuration options in config.php:
<code php>
$CFG->session_handler_class = '\core\session\redis';
$CFG->session_redis_host = '127.0.0.1';
$CFG->session_redis_port = 6379; // Optional.
$CFG->session_redis_database = 0; // Optional, default is db 0.
$CFG->session_redis_prefix = ''; // Optional, default is don't set one.
$CFG->session_redis_acquire_lock_timeout = 120;
$CFG->session_redis_lock_expire = 7200;
</code>

== Read only sessions ==

There is an experimental feature in Moodle 3.9 allowing certain pages to start readonly sessions which do not require a write lock with the aim of high performance at scale.

https://tracker.moodle.org/browse/MDL-58018

Details TBA

==See also==
* [[Sessions FAQ]]

[[cs:admin/setting/sessionhandling]]
[[ja:セッションハンドリング]]
[[de:Sitzungsinformationen]]
[[es:Manejo de la sesión]]
[[fr:Gestion des sessions]]

Session handling

2020-02-02T06:52:42Z

Brendanheywood: Add section on readonly sessions

{{Server settings}}
An administrator can change the following settings in 'Session Handling' in the Site administration.

Once someone logs in to your Moodle server, the server starts a session. The session data allows the server to track users as they access different pages.

==Use database for session information==

Moodle needs to store the session data in some storage. By default either file or database session storage is selected, this option allows admin to change it. Large installation should use memcached driver described below.

Note that this option disappears after setting the $CFG->session_handler_class in config.php file.

==Timeout==

If users don't load a new page during the amount of time set here, Moodle will end their session and log them out.

Be sure this time frame is long enough to cover the longest test your teachers may offer. If a student is logged out while they are taking a test, their responses to the test questions may be lost.

==Cookie prefix==

Most of the time, you can leave this blank, unless you are running more than one Moodle site on the same server. In this case, you will want to customize the name of the cookie each Moodle site uses to track the session. This enables you to be logged into more than one Moodle site at the same time.

Note: If you change "Cookie prefix" or "Cookie path" you will need to login again as the changes take effect immediately.

==Cookie path==

The relative path to this Moodle installation, this may be used to force sending of Moodle session cookie to parent directories. Invalid values are ignored automatically.

==Cookie domain==

This can be used to send session cookies to higher domains instead of just the server domain. This may be useful for some SSO solutions. Invalid values are ignored automatically.

==Session drivers==
User sessions may be stored in different backends. Session drivers can be configured only in config.php file - see examples in config-dist.php file.

===Memcached session driver===
The Memcached session driver is the fastest driver. It requires external memcached server and memcached PHP extension. Server cluster nodes must use shared session storage.

Configuration options in config.php:
<code php>
$CFG->session_handler_class = '\core\session\memcached';
$CFG->session_memcached_save_path = '127.0.0.1:11211';
$CFG->session_memcached_prefix = 'memc.sess.key.';
$CFG->session_memcached_acquire_lock_timeout = 120;
$CFG->session_memcached_lock_expire = 7200; // Ignored if memcached extension <= 2.1.0
</code>

Notes:
* Make sure the memcached server has enough memory.
* Use different prefix when storing sessions from multiple Moodle sites in one server.
* If PECL memcached extension version installed is less that 2.2.0, the locking works differently from other drivers - the lock is expired/released at the end of timeout - see MDL-42485.
* '''Don't use the same memcached server for both sessions and MUC. Events triggering MUC caches to be purged leads to MUC purging the memcached server - thus terminating ALL sessions.'''
* The <code php>$CFG->session_memcached_number_of_replicas</code> option is no longer supported.

For windows users, PHP.net only supplies binaries for memcache, (and not memcached). (http://windows.php.net/downloads/pecl/releases/)

(As of 2.7, two different contribs exist for memcache session handling - see MDL-42011 - it seems the OU one doesn't use prefix/lock_expire for some reason... possibly better to use the catalyst patch, where the only difference to the above config.php is the spelling of memcache(d).)

===File session driver===
This driver is used by default in new installation.

Configuration options in config.php:
<code php>
$CFG->session_handler_class = '\core\session\file';
$CFG->session_file_save_path = $CFG->dataroot.'/sessions';
</code>

Notes:
* File based sessions require file system that supports file locking.

===Database session driver===
This type of driver was used by default in Moodle 2.0-2.5.

<code php>
$CFG->session_handler_class = '\core\session\database';
$CFG->session_database_acquire_lock_timeout = 120;
</code>

Notes:
* DB sessions are not compatible with MyISAM database engine.
* If you are using MySQL/MariaDB make sure that \'max_allowed_packet\' in my.cnf (or my.ini) is at least 4M.
* The performance is relatively low, it is not recommended for large sites.

===Redis session driver===

The [[Redis]] session driver is available in Moodle 3.1.3 onwards (see MDL-54606). It requires a [[Redis_cache_store#Installing_Redis_server|Redis server]] and the [[Redis_cache_store#Installing_Redis_php_driver|Redis extension]].

Configuration options in config.php:
<code php>
$CFG->session_handler_class = '\core\session\redis';
$CFG->session_redis_host = '127.0.0.1';
$CFG->session_redis_port = 6379; // Optional.
$CFG->session_redis_database = 0; // Optional, default is db 0.
$CFG->session_redis_prefix = ''; // Optional, default is don't set one.
$CFG->session_redis_acquire_lock_timeout = 120;
$CFG->session_redis_lock_expire = 7200;
</code>

== Read only sessions ===

There is an experimental feature in Moodle 3.9 allowing certain pages to start readonly sessions which do not require a write lock with the aim of high performance at scale.

https://tracker.moodle.org/browse/MDL-58018

Details TBA

==See also==
* [[Sessions FAQ]]

[[cs:admin/setting/sessionhandling]]
[[ja:セッションハンドリング]]
[[de:Sitzungsinformationen]]
[[es:Manejo de la sesión]]
[[fr:Gestion des sessions]]

Custom certificate module

2017-12-11T05:42:14Z

Brendanheywood: /* Helpful links */

{{Infobox plugin
|type = Activity
|entry = https://moodle.org/plugins/mod_customcert
|tracker = https://github.com/markn86/moodle-mod_customcert/issues
|discussion = https://moodle.org/mod/forum/view.php?id=7163
|maintainer = [[User:Mark Nelson|Mark Nelson]]
|float = right
}}
==Description==
The [https://moodle.org/plugins/mod_customcert custom certificate module] allows the generation of dynamic PDF certificates with complete customisation via the web browser. It is different from the [https://moodle.org/plugins/mod_certificate certificate module] which requires PHP and FTP access in order to customise its appearance.

==Installation==
There are two installation methods that are available.

Follow one of these, then log into your Moodle site as an administrator and visit the notifications page to complete the install.
===Git===

This requires Git being installed. If you do not have Git installed, please visit the Git website.

Once you have Git installed, simply visit your Moodle mod directory and clone the repository using the following command.

<code>git clone https://github.com/markn86/moodle-mod_customcert.git customcert</code>

Then checkout the branch corresponding to the version of Moodle you are using with the following command. Make sure to replace MOODLE_32_STABLE with the version of Moodle you are using.

<code>git checkout MOODLE_32_STABLE</code><br />
Use <code>git pull</code> to update this repository periodically to ensure you have the most recent updates.
===Download the Zip===

Visit the Moodle plugins website and download the zip corresponding to the version of Moodle you are using. Extract the zip and place the 'customcert' folder in the mod folder in your Moodle directory.

==Site settings==

To visit the site settings log in as a user with appropriate permissions and visit 'Site administration' > 'Plugins' > 'Custom certificate'.

[[File:Custom_certificate_site_settings.png]]

===Show position X and Y===

This will show the X and Y position when editing of an element, allowing the user to accurately specify the location.

This isn't required if you plan on solely using the drag and drop interface for this purpose.

===Manage templates===

This link will take you to a new screen where you will be able to manage templates.

===Upload image===

This link will take you to a new screen where you will be able to upload images. Images uploaded using this method will be available throughout your site to all users who are able to create a custom certificate.

==Managing templates==
Templates allow a person with the appropriate permissions to create a site-wide template that can then be used by users when adding a certificate to a course, saving them from re-creating the same certificate over and over again. To create a template log in as a user who has the appropriate permissions and visit 'Site administration' > 'Plugins' > 'Custom certificate' and click on the link 'Manage templates'.

[[File:Custom_certificate_manage_templates.png]]

Here you will see a list of templates that have already been created. You can choose to edit these templates, delete them or create a new one. We will be creating a new template - start by clicking on 'Create template'.

[[File:Custom_certificate_edit_page.png]]

The name here is what will be displayed to the users when they are creating a certificate in a course and would like to choose a template to load. You can add elements to the template, customise them and rearrange their position. This process is discussed later when we talk about adding a custom certificate to a course and then customising it.

==Adding a custom certificate to a course==

The custom certificate plugin once installed can be added just like any other activity in Moodle. Visit a course, turn editing on and click to add an activity.

[[File:Custom_certificate_add_activity_page.png]]

===Certificate options===

====Allow anyone to verify a certificate====

Each certificate when issued is assigned a unique code. It is possible to have this code displayed on the certificate by adding it as an element. To validate a certificate a person (eg. employer) may want to enter the code displayed on the certificate to confirm that it is indeed authentic. To accomplish this a logged in user requires the capability 'mod/customcert:verifycertificate', however with this setting set to 'Yes' any person with the verification link (including users not logged in) can do this.

====Email students/teachers/others====

These settings enable the emailing of a certificate when a user is able to view it. The certificate may be hidden due to [[https://docs.moodle.org/en/Restrict_access access restrictions]], such as requiring the completion of another activity. A [[https://docs.moodle.org/en/Scheduled_tasks scheduled task]] runs that processes all the certificates that have any of these settings enabled and collects all the users to email that have not been emailed yet and are able to view the certificate and emails them the PDF.

====Required minutes in course====

This is the number of minutes a user is required to be in a course before they are able to view a certificate. This uses the logs in Moodle and hence can not guarantee the result to be 100% accurate.

====Set protection====

This determines what protection we want to set on the PDF.

===Editing a custom certificate===

Once you have added a certificate to your course you can then choose to edit the appearance of it. To do this view the certificate to be taken to the following page.

[[File:Custom_certificate_edit_menu.png]]

Here you can click on the cog on the top right and select 'Edit custom certificate'.

[[File:Custom_certificate_edit_page_with_items.png]]

On the edit page you can see a list of the elements that have already been added to the certificate. You can edit, delete and move these elements. The order of these elements determine when they are rendered on the PDF. So, if you were to add a background image you would want this rendered first.

You can also choose to load a template on this page. If you also have the permissions to manage templates you will also be shown the link to the manage templates page.

===Adding/editing an element===

[[File:Custom_certificate_element_list.png]]

The above is the list of items that come with this plugin. These are [[https://docs.moodle.org/dev/Subplugins sub-plugins]] and are fully customisable allowing the community to generate plugins and share them without having to hack the plugin code.

When editing a custom certificate you can choose to add an element which will take you to the page to edit them.

[[File:Custom_certificate_edit_element.png]]

Each element defines what characteristics you can edit. In the above example we are editing the 'Student name' element. The site setting 'Show position X and Y' has been enabled which is why 'Position X' and 'Position Y' are shown.

===Repositioning elements===

When editing a custom certificate under the list of elements there is a link 'Reposition elements' that will take you to a page where you can drag and drop the elements. While on this page you can also click on the elements to bring up a dialogue that will allow you to edit its properties without having to go back to the edit custom certificate page.

[[File:Custom_certificate_reposition_elements.png]]

==Viewing issued certificates==

To view issued certificates a user with the appropriate permissions can simply click on the certificate and click on the link 'View X issued custom certificates'.

[[File:Custom_certificate_view_issued_certificates.png]]

Once you click on the link you can view the users who have been issued this certificate and also download their version of the certificate.

[[File:Custom_certificate_view_issued_certificates_list.png]]

==Verifying certificates==

Each certificate when issued is assigned a unique code. To validate a certificate a person (eg. employer) may want to enter the code displayed on the certificate to confirm that it is indeed authentic. With the setting 'Allow anyone to verify a certificate' enabled any person with the verification link (including users not logged in) can verify a certificate, however if it is not set, a user with the appropriate permissions ('mod/customcert:verifycertificate') can do this by clicking on the certificate to gain access to the link.

[[File:Custom_certificate_edit_menu.png]]

Here you can click on the cog on the top right and select 'Verify certificate'.

[[File:Custom_certificate_verify_certificate_page.png]]

Here you can enter the code to verify its authenticity.

==My certificates==

It is possible that a user may be in several courses each with their own custom certificate activity. It would be time consuming for the user to visit every course to review their certificate. In order to avoid this there is a page where the user can view all the certificates they have received.

[[File:Custom_certificate_profile_page.png]]

On the user's profile page under 'Miscellaneous' the user can click on 'My certificates' which will take them to a page listing all their certificates with the option of downloading them.

[[File:Custom_certificate_my_certificates_page.png]]

==Helpful links==
See [https://moodle.org/plugins/mod_customcert the plugin page], the [https://github.com/markn86/moodle-mod_customcert/issues tracker page] and the [https://moodle.org/mod/forum/view.php?id=7163 Moodle forum].

[[Add_fonts_for_embedding]] - see this page for details of adding more fonts for use in TCPDF

==Did you find this plugin useful?==
Click on the 'Add to my favourites' link in [https://moodle.org/plugins/mod_customcert the plugin page].