MoodleDocs - User contributions [en]

MySQL full unicode support

2017-04-26T10:29:51Z

CHRISF:

{{Environment}}
==UTF-8==

UTF-8 is a character encoding that most websites use. It encodes each of the 1,112,064 valid code points. To store all of this information, four bytes is required. The most popular values are in the three byte region. MySQL by default only uses a three byte encoding and so values in the four byte range (eg. Asian characters and Emojis) can not be stored. Any attempt to enter a text that contains four byte characters will result in a Moodle database error.

MySQL does provide full four byte UTF-8 support, but it requires certain database settings to be configured. From version 3.3 on Moodle uses full UTF-8 for both MySQL and MariaDB by default. Existing databases will still run with partial support, but it is recommended to move over to full support.

Moodle comes with a Command Line Interface (CLI) script for converting to full UTF-8 for MySQL (and MariaDB). Before Moodle versions 3.1.5 and 3.2.2 this conversion tool would only change the Collation to some variant of 'utf8_bin'. 'utf8_unicode_ci' was the recommended Collation. We now recommend using 'utf8mb4_unicode_ci' which supports four byte characters (utf8_unicode_ci only supports three).

This script will attempt to change the database Collation, Character set, default table settings and column definitions.

To summarise:

* Fresh installs of Moodle 3.1.5 and 3.2.2 onwards will use utf8mb4 by default, if the database server is configured appropriately (see below).
* Sites upgrading to Moodle 3.1.5 or 3.2.2 can use the script to update to utf8mb4. In Moodle 3.3 a warning will show that the database isn't using full UTF-8 support and suggest moving to 'utf8mb4_unicode_ci', but you may choose to keep using 'utf8_*'.

===File format===

To allow for large indexes on columns that are a varchar, a combination of settings needs to be set. The file format for the system needs to be using "Barracuda". This allows for the row format to be set to "Compressed" or "Dynamic". To enable this setting see the upgrade steps listed below.

===File per table===

To enable this setting see the upgrade steps listed below.

===Large prefix===

This in conjunction with the row format being either "Compressed" or "Dynamic" allows for large varchar indexes above 191 characters.
To enable this setting see the upgrade steps listed below.

==Steps to upgrade==

Most important: Please backup your database before making any changes or running the CLI script.

* Change configuration settings for MySQL (exactly the same for MariaDB). This step is optional. You can run the script and it will try and make these changes itself. If errors occur then try manually changing these settings as listed below.
** On Linux based systems you will want to alter my.cnf. This may be located in '/etc/mysql/'.
** Make the following alterations to my.cnf:
<code>
[client]
default-character-set = utf8mb4

[mysqld]
innodb_file_format = Barracuda
innodb_file_per_table = 1
innodb_large_prefix

character-set-client-handshake = FALSE
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci

[mysql]
default-character-set = utf8mb4
</code>
* Restart your MySQL server.
* Run the CLI script to convert to the new Character set and Collation (requires Moodle 3.1.5, 3.2.2 or newer):
<pre>
$ php admin/cli/mysql_collation.php --collation=utf8mb4_unicode_ci
</pre>

'''WARNING: For large sites, this script will be slow. For very large sites it may take hours or even days! It is recommended to dump and reimport your data according to [[Converting your MySQL database to UTF8#Converting_a_database_containing_tables|this guide]] '''

* Adjust the $CFG->dboptions Array in your '''config.php''' to make sure that Moodle uses the right Collation when connecting to the MySQL Server:
<pre>
$CFG->dboptions = array(
…
'dbcollation' => 'utf8mb4_unicode_ci',
…
);
</pre>
* Try adding some Emojis 🇦🇺👏🎓 to your Moodle site to verify that the upgrade was successful.

[[Category:Environment|UTF-8]]
[[Category:UTF-8]]

[[es:MySQL soporte unicode completo]]
[[fr:Support unicode complet pour MySQL]]

error/moodle/invalidsesskey

2017-02-21T18:17:44Z

CHRISF: Correct the PHP ini setting name

Some reasons why you might have got an "Invalid Sesskey" message are:

# Your site doesn't have the PHP setting "session.auto_start=0" (see [[Installing_Moodle#Software|Installing Moodle - software]])
# You logged out at some time between opening the form and submitting it.
# You have followed a bad link to a form script.
# Your database has an incorrect value for sessioncookiepath in the mdl_config table.
# You edited the code in a file on the server while logged in to your moodle website.

==See also==

*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=105891 incorrect sesskey - occasional failures] forum discussion

[[Category:Error|Invalidsesskey]]

[[es:error/moodle/invalidsesskey]]

Development:File API

2010-12-02T12:09:32Z

CHRISF:

{{Work in progress}}
{{Infobox Project
|name = File API
|state = Implemented
|tracker = MDL-14589
|discussion = n/a
|assignee = [[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]]
}}
{{Moodle 2.0}}

==Objectives==

The goals of the new File API are:

* allow files to be stored within Moodle, as part of the content (as we do now).
* use a consistent and flexible approach for all file handling throughout Moodle.
* give modules control over which users can access a file, using capabilities and other local rules.
* make it easy to determine which parts of Moodle use which files, to simplify operations like backup and restore.
* track where files originally came from.
* avoid redundant storage, when the same file is used twice.
* fully support Unicode file names, irrespective of the capabilities of the underlying file system.

==Overview==

The File API is a set of core interfaces to allow the rest of Moodle to store, serve and manage files. It applies only to files that are part of the Moodle site's content. It is not used for internal files, such as those in the following subdirectories of dataroot: temp, lang, cache, environment, filter, search, sessions, upgradelogs, ...

The API can be subdivided into the following parts:
; File storage
: Low level file storage without access control information. Stores the content of files on disc, with metadata in associated database tables.
; File serving
: Lets users accessing a Moodle site get the files (file.php, draftfile.php, pluginfile.php, userfile.php, etc.)
:* Serve the files on request
:* with appropriate security checks
; File related user interfaces
: Provides the interface for (lib/form/file.php, filemanager.php, filepicker.php and files/index.php, draftfiles.php)
:* Form elements allowing users to select a file using the Repository API, and have it stored within Moodle.
:* UI for users to manage their files, replacing the old course files UI
; File browsing API
: Allows code to browse and optionally manipulate the file areas
:* find information about available files in each area.
:* print links to files.
:* optionally move/rename/copy/delete/etc.

== File API internals ==

=== File storage on disk ===

Files are stored in $CFG->dataroot (also known as moodledata) in the filedir subfolder.

Files are stored according to the SHA1 hash of their content. This means each file with particular contents is stored once, irrespective of how many times it is included in different places, even if it is referred to by different names. (This idea comes from the git version control system.) To relate a file on disc to a user-comprehensible path or filename, you need to use the ''files'' database table. See the next section.

Suppose a file has SHA1 hash 081371cb102fa559e81993fddc230c79205232ce. Then it will be stored in on disc as moodledata/filedir/08/13/71/081371cb102fa559e81993fddc230c79205232ce.

This means Moodle can not store two files with the same SHA1 hash, luckily it is extremely unlikely that this would ever happen. Technically it is also possible to implement reliable collision tests (with some performance cost), for now we just test file lengths in addition to SHA1 hash.

=== Files table ===

This table contains one entry for each usage of a file. Enough information is kept here so that the file can be fully identified and retrieved again if necessary. It is necessary because some databases have hard limit on index size.

If, for example, the same image is used in a user's profile, and a forum post, then there will be two rows in this table, one for each use of the file, and Moodle will treat the two as separate files, even though the file is only stored once on disc.

{| class="nicetable"
! Field
! Type
! Default
! Info
|-
| '''id'''
| int(10)
| auto-incrementing
| The unique ID for this file.
|-
| '''contenthash'''
| varchar(40)
|
| The sha1 hash of content.
|-
| '''pathnamehash'''
| varchar(40)
|
| The sha1 hash of "/contextid/component/filearea/itemid/filepath/filename.ext" - prevents file duplicates and allows fast lookup. It is necessary because some databases have hard limit on index size.
|-
| '''contextid'''
| int(10)
|
| The context id defined in context table - identifies the instance of plugin owning the file.
|-
| '''component'''
| varchar(50)
|
| Like "mod_forum", "course", "mod_assignment", "backup"
|-
| '''filearea'''
| varchar(50)
|
| Like "submissions", "intro" and "content" (images and swf linked from summaries), etc.; "blogs" and "userfiles" are special case that live at the system context.
|-
| '''itemid'''
| int(10)
|
| Some plugin specific item id (eg. forum post, blog entry or assignment submission or user id for user files)
|-
| filepath
| text
|
| relative path to file from module content root, useful in Scorm and Resource mod - most of the mods do not need this
|-
| filename
| varchar(255)
|
| The full Unicode name of this file (case sensitive)
|-
| '''userid'''
| int(10)
| NULL
| Optional - general user id field - meaning depending on plugin
|-
| filesize
| int(10)
|
| size of file - bytes
|-
| mimetype
| varchar(100)
| NULL
| type of file
|-
| status
| int(10)
|
| general file status flag - will be used for lost or infected files
|-
| source
| text
|
| file source - usually url
|-
| author
| varchar(255)
|
| original author of file, used when importing from other systems
|-
| license
| varchar(255)
|
| license type, empty means site default
|-
| timecreated
| int(10)
|
| The time this file was created
|-
| timemodified
| int(10)
|
| The last time the file was last modified
|}

Indexes:
* non-unique index on (contextid, component, filearea, itemid)
* non-unique index on (contenthash)
* unique index on (pathnamehash).

The plugin type does not need to be specified because it can be derived from the context. Items like blog that do not have their own context will use their own file area inside a suitable context. In this case, the user context.

Entries with filename = '.' represent directories. Directory entries like this are created automatically when a file is added within them.

Note: 'files' plural is used even thought that goes against the [[Development:Database|coding guidelines]] because 'file' is a reserved word in some SQL dialects.

===Implementation of basic operations===

'''Each plugin may directly access only files in own context and areas!'''

Low level access API is defined in ''file_storage'' class which is obtained from <code>get_file_storage()</code>.

====Storing a file====

# Calculate the SHA1 hash of the file contents.
# Check if a file with this SHA1 hash already exists on disc in file directory or file trash. If not, store the file there.
# Add the record for this file to the files table using the low level address

====Reading a file====

# Fetch the record (which includes the SHA1 hash) for the file you want from the files table. You can fetch either all area files or quickly get one file with a specific contenthash.
# Retrieve the contents using the SHA1 hash from the file directory.

====Deleting a file====

# Delete the record from the files table.
# Verify if some other file is still needing the content, if not move the content file into file trash
# Later, admin/cron.php deletes content files from trash directory

== File serving ==

Deals with serving of files - browser requests file, Moodle sends it back. We have three main files. It is important to setup slasharguments on server properly (file.php/some/thing/xxx.jpg), any content that relies on relative links can not work without it (scorm, uploaded html pages, etc.).

=== legacy file.php ===

Serves legacy course files, the file name and parameter structure is critical for backwards compatibility of existing course content.

/file.php/courseid/dir/dir/filename.ext

Internally the files are stored in <code>array('contextid'=>$coursecontextid, 'component;=>'course', 'filearea'=>'legacy', 'itemid'=>0)</code>

The legacy course files are completely disabled in all new courses created in 2.0. The major problem here is to how to educate our users that they can not make huge piles of files in each course any more.

=== pluginfile.php ===
All plugins should use this script to serve all files.
* plugins decide about access control
* optional XSS protection - student submitted files must not be served with normal headers, we have to force download instead; ideally there should be second wwwroot for serving of untrusted files
* links to these files are constructed on the fly from the relative links stored in database, this means that plugin may link only own files

Absolute file links need to be rewritten if html editing allowed in plugin. The links are stored internally as relative links. Before editing or display the internal link representation is converted to absolute links using simple str_replace() @@thipluginlink/summary@@/image.jpg --> /pluginfile.php/assignmentcontextid/intro/image.jpg, it is converted back to internal links before saving.

Script parameters are virtual file names, in most cases the parameters match the low level file storage, but they do not have to:

/pluginfile.php/contextid/areaname/arbitrary/params/or/dirs/filename.ext

pluginfile.php detects the type of plugin from context table, fetches basic info (like $course or $cm if appropriate) and calls plugin function (or later method) which does the access control and finally sends the file to user. ''areaname'' separates files by type and divides the context into several subtrees - for example ''summary'' files (images used in module intros), post attachments, etc.

==== Assignment example ====

/pluginfile.php/assignmentcontextid/mod_assignment/intro/someimage.jpg
/pluginfile.php/assignmentcontextid/mod_assignment/submission/submissionid/attachmentname.ext
/pluginfile.php/assignmentcontextid/mod_assignment/allsubmissions/groupid/allsubmissionfiles.zip

The last line example of virtual file that should created on the fly, it is not implemented yet.

====scorm example====

/pluginfile.php/scormcontextid/mod_scorm/intro/someimage.jpg
/pluginfile.php/scormcontextid/mod_scorm/content/revisionnumber/dir/somescormfile.js

The revision counter is incremented when any file changes in order to prevent caching problems.

====quiz example====

pluginfile.php/quizcontextid/mod_quiz/intro/niceimage.jpg

====questions example====

This section was out of date. See [[Development:File_storage_conversion_Quiz_and_Questions]] for the latest thinking.

====blog example====
Blog entries or notes in general do not have context id (because they live in system context, SYSCONTEXTID below is the id of system context).
The note attachments are always served with XSS protection on, ideally we should use separate wwwroot for this. Access control can be hardcoded.

/pluginfile.php/SYSCONTEXTID/blog/attachment/blogentryid/attachmentname.ext

Internally stored in <code>array('contextid'=>SYSCONTEXTID, 'component'=>'blog', 'filearea'=>'attachment', 'itemid'=>$blogentryid)</code>

/pluginfile.php/SYSCONTEXTID/blog/post/blogentryid/embeddedimage.ext

Internally stored in <code>array('contextid'=>SYSCONTEXTID, 'component'=>'blog', 'filearea'=>'post', 'itemid'=>$blogentryid)</code>

=== Temporary files ===
Temporary files are usually used during the lifetime of one script only.
uses:
* exports
* imports
* processing by executable files (latex, mimetex)

These files should never use utf-8 file names.

=== Legacy file storage and serving ===
Going to use good-old separate directories in $CFG->dataroot.

file serving and storage:
# user avatars - user/pix.php
# group avatars - user/pixgroup.php
# tex, algebra - filter/tex/* and filter/algebra/*
# rss cache (?full rss rewrite soon?) - backwards compatibility only rss/file.php

only storage:
#sessions

== File browsing API ==

This is what other parts of Moodle use to access files that they do not own.

=== Class: file_browser ===

=== Class: file_info and subclasses ===

== File related user interfaces ==

All files are obtained through from the file repositories.

=== Formslib fields ===
* file picker
* file manager
* file upload (obsolete, do not use)

=== Integration with the HTML editor ===

Each instance of the HTML editor can be told to store related files in a particular file area.

During editing, files are stored in a draft files area. Then when the form is submitted they are moved into the real file area.

Files are selected using the repository file picker.

=== Legacy file manager ===

Available only for legacy reasons. It is not supposed to be used.

All the contexts, file areas and files now form a single huge tree structure, although each user only has access to certain parts of that tree. The file manager (files/index.php) allow users to browse this tree, and manage files within it, according to the level of permissions they have.

Single pane file manager is hard to implement without drag & drop which is notoriously problematic in web based applications. I propose to implement a two pane commander-style file manager. Two pane manager allows you to easily copy/move files between two different contexts (ex: courses).

File manager must not interact directly with filesystem API, instead each module should return traversable tree of files and directories with both real and localised names (localised names are needed for dirs like backupdata).

== Backwards compatibility ==

=== Content backwards compatibility ===

This should be preserved as much as possible. This will involve rewriting links in content during the upgrade to 2.0.

Some new features (like resource sharing - if implemented) may not work with existing data that still uses files from course files area.

There might be a breakage of links due to special characters stripping in uploaded files which will not match the links in uploaded html files any more. This should not be very common I hope.

===Code backwards compatibility===

Other Moodle code (for example plugins) will have to be converted to the new APIs. See [[Development:Using_the_file_API]] for guidance.

It is not possible to provide backwards-compatibility here. For example, the old $CFG->dataroot/$courseid/ will no longer exist, and there is no way to emulate that, so we won't try.

== Upgrade and migration ==

When a site is upgraded to Moodle 2.0, all the files in moodledata will have to be migrated. This is going to be a pain, like DML/DDL was :-(

The upgrade process should be interruptible (like the Unicode upgrade was) so it can be stopped/restarted any time.

=== Migration of content ===

* resources - move files to new resource content file area; can be done automatically for pdf, image resources; definitely not accurate for uploaded web pages
* questions - image file moved to new area, image tag appended to questions
* moddata files - the easiest part, just move to new storage
* coursefiles - there might be many outdated files :-( :-(
* rss feeds links in readers - will be broken, the new security related code would break it anyway

=== Moving files to files table and file pool ===

The migration process must be interruptable because it might take a very long time. The files would be moved from old location, the restarting would be straightforward.

Proposed stages:
#migration of all course files except moddata - finish marked by some $CFG->files_migrated=true; - this step breaks the old file manager and html editor integration
#migration of blog attachments
#migration of question files
#migration of moddata files - each module is responsible to copy data from converted coursefiles or directly from moddata which is not converted automatically

Some people use symbolic links in coursefiles - we must make sure that those will be copied to new storage in both places, though they can not be linked any more - anybody wanting to have content synced will need to move the files to some repository and set up the sync again.

::Talked about a double task here, when migrating course files to module areas:
::# Parse html files to detect all the dependencies and move them together.
::# Fallback in pluginfile.php so, if something isn't found in module filearea, search for it in course filearea, copying it and finally, serving it.

:: Also we talked about the possibility of add a new setting to resource in order to define if it should work against old coursefiles or new autocontained file areas. Migrated resources will point to old coursefiles while new ones will enforce autocontained file areas.

:: it seems that only resource files will be really complex (because allow arbitrary HTML inclusion). The rest (labels, intros... doesn't) and should be easier to parse.

::[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 19:00, 29 June 2008 (CDT)

== Other issues ==

=== Unicode support in zip format ===

Zip format is an old standard for compressing files. It was created long before Unicode existed, and Unicode support was only recently added. There are several ways used for encoding of non-ASCII characters in path names, but unfortunately it is not very standardised. Most Windows packers use DOS encoding.

Client software:
* Windows built-in compression - bundled with Windows, non-standard DOS encoding only
* WinZip - shareware, Unicode option (since v11.2)
* TotalCommander - shareware, single byte(DOS) encoding only
* 7-Zip - free, Unicode or DOS encoding depending on characters used in file name (since v4.58beta)
* Info-ZIP - free, uses some weird character set conversions

PHP extraction:
* Info-ZIP binary execution - no Unicode support at all, mangles character sets in file names (depends on OS, see docs), files must be copied to temp directory before compression and after extraction
* PclZip PHP library - reads single byte encoded names only, problems with random problems and higher memory usage.
* Zip PHP extension - kind of works in latest PHP versions

Large file support:
PHP running under 32bit operating systems does not support files >2GB (do not expect fix before PHP 6). This might be a potential problem for larger backups.

Tar Alternative:
* tar with gzip compression - easy to implement in PHP + zlib extension (PclTar, Tar from PEAR or custom code)
* no problem with unicode in *nix, Windows again expects DOS encoding :-(
* seems suitable for backup/restore - yay!

Summary:
# added zip processing class that fully hides the underlying library
# using single byte encoding "garbage in/garbage out" approach for encoding of files in zip archives; add new 'zipencoding' string into lang packs (ex: cp852 DOS charset for Czech locale) and use it during extraction (we might support true unicode later when PHP Zip extension does that)

== Not implemented yet ==
* antivirus scanning - this needs a different api because the upload of files is now handled via repository plugins

== See also ==

* [[Development:Using the file API]]
* [[Development:Repository API]]
* [[Development:Portfolio API]]
* [[Development:Resource module file API migration]]
* MDL-14589 - File API Meta issue

{{CategoryDeveloper}}
[[Category:Files]]

[[ja:開発:ファイルAPI]]
[[ru:Development:File_API]]

System paths

2007-11-05T13:31:11Z

CHRISF: /* Path to unzip */

Location: ''Administration > Server > System Paths''

==GD version==

GD is a graphics library that manipulates graphics. It's used to create thumbnail images from uploaded files and other graphics on the fly. If you don't know what version is installed, leave this on the original setting.

'''Note''': When setting the system paths on Windows systems, use of the 8.3 notation for the path and filename is preferred. So instead of entering ''c:\program files\path to aspell\aspell.exe'', enter ''c:\progra~1\path~1\aspell.exe''. Check the exact 8.3 path using the ''dir /x'' command at the prompt.

==Path to zip==

When compressing files Moodle uses either the PclZip library or the external zip program. The external program is faster, so if you are experiencing slow backups or other performance problems, try setting the path to your zip program. On Unix/Linux systems, find the path as follows using the which program:

[root@moodle ~]# which zip
/usr/bin/zip

In this example the path to enter is ''/usr/bin/zip''.

This program must be the PKZIP-compatible ''zip''. The GNU zip program ''gzip'' cannot handle the type of zip files required by Moodle.

On Windows systems, download [[http://gnuwin32.sourceforge.net/packages/zip.htm the GNU Win32 Zip complete package]]. Run the setup.exe program to install and use the search facility in Explorer to find the location of the zip.exe file. The path should look like:

c:\program files\gnuwin32\bin\zip.exe

If this does not work, shorten it to the 8.3 notation:

c:\progra~1\gnuwin32\bin\zip.exe

==Path to unzip==

When uncompressing files Moodle uses either the PclZip library or the external unzip program. As with the zip program, the external program is faster, so if you are experiencing slow backups or other performance problems, try setting the path to your unzip program. On Unix/Linux systems, find the path as follows using the which program:

[root@moodle ~]# which unzip
/usr/bin/unzip

In this example the path to enter is ''/usr/bin/unzip''.

This program must be the PKZIP-compatible ''unzip''. The GNU unzip program ''gunzip'' cannot handle the type of zip files created by Moodle.

On Windows systems, download [[http://gnuwin32.sourceforge.net/packages/unzip.htm the GNU Win32 Zip complete package]]. Run the setup.exe program to install and use the search facility in Explorer to find the location of the unzip.exe file. The path should look like:

c:\program files\gnuwin32\bin\unzip.exe

If this does not work, shorten it to the 8.3 notation:

c:\progra~1\gnuwin32\bin\unzip.exe

==Path to aspell==

To use spell-checking within the [[HTML editor]], you MUST have aspell 0.50 or later installed on your server, and you must specify the correct path to access the aspell binary. On Unix/Linux systems use the which program to determine the path:

[root@moodle ~]# which aspell
/usr/bin/aspell

In this example the path to enter is ''/usr/bin/aspell''.

On a Windows system, download and install [http://aspell.net/win32 GNU aspell] together with at least one dictionary and then use the search facility in Explorer to find the aspell.exe file. The path should look like:

c:\program files\aspell\bin\aspell.exe

It can be best to install aspell in c:\aspell or use the 8.3 notation if you are installing in ''c:\program files'' so that the path looks like

c:\progra~1\aspell\bin\aspell.exe

*[[Configuring aspell on Mac OS X]]
*[[Configuring aspell on Windows 2003 Server]]

==External links==

*[http://aspell.sourceforge.net/ GNU Aspell]
*[http://aspell.net/win32/ GNU Aspell (Win32 version)]
*[http://sourceforge.net/project/showfiles.php?group_id=9328 Du, Zip and Unzip binaries for Win32]

==See also==

*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=28465 Check your aspell installation] forum discussion
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=41831 When will we be able to use TinyCME in Moodle?] forum discussion

[[Category:Administrator]]

System paths

2007-11-05T13:30:31Z

CHRISF: /* Path to zip */

Location: ''Administration > Server > System Paths''

==GD version==

GD is a graphics library that manipulates graphics. It's used to create thumbnail images from uploaded files and other graphics on the fly. If you don't know what version is installed, leave this on the original setting.

'''Note''': When setting the system paths on Windows systems, use of the 8.3 notation for the path and filename is preferred. So instead of entering ''c:\program files\path to aspell\aspell.exe'', enter ''c:\progra~1\path~1\aspell.exe''. Check the exact 8.3 path using the ''dir /x'' command at the prompt.

==Path to zip==

When compressing files Moodle uses either the PclZip library or the external zip program. The external program is faster, so if you are experiencing slow backups or other performance problems, try setting the path to your zip program. On Unix/Linux systems, find the path as follows using the which program:

[root@moodle ~]# which zip
/usr/bin/zip

In this example the path to enter is ''/usr/bin/zip''.

This program must be the PKZIP-compatible ''zip''. The GNU zip program ''gzip'' cannot handle the type of zip files required by Moodle.

On Windows systems, download [[http://gnuwin32.sourceforge.net/packages/zip.htm the GNU Win32 Zip complete package]]. Run the setup.exe program to install and use the search facility in Explorer to find the location of the zip.exe file. The path should look like:

c:\program files\gnuwin32\bin\zip.exe

If this does not work, shorten it to the 8.3 notation:

c:\progra~1\gnuwin32\bin\zip.exe

==Path to unzip==

When uncompressing files Moodle uses either the PclZip library or the external unzip program. As with the zip program, the external program is faster, so if you are experiencing slow backups or other performance problems, try setting the path to your unzip program. On Unix/Linux systems, find the path as follows using the which program:

[root@moodle ~]# which unzip
/usr/bin/unzip

In this example the path to enter is ''/usr/bin/unzip''.

On Windows systems, download [[http://gnuwin32.sourceforge.net/packages/unzip.htm the GNU Win32 Zip complete package]]. Run the setup.exe program to install and use the search facility in Explorer to find the location of the unzip.exe file. The path should look like:

c:\program files\gnuwin32\bin\unzip.exe

If this does not work, shorten it to the 8.3 notation:

c:\progra~1\gnuwin32\bin\unzip.exe

==Path to aspell==

To use spell-checking within the [[HTML editor]], you MUST have aspell 0.50 or later installed on your server, and you must specify the correct path to access the aspell binary. On Unix/Linux systems use the which program to determine the path:

[root@moodle ~]# which aspell
/usr/bin/aspell

In this example the path to enter is ''/usr/bin/aspell''.

On a Windows system, download and install [http://aspell.net/win32 GNU aspell] together with at least one dictionary and then use the search facility in Explorer to find the aspell.exe file. The path should look like:

c:\program files\aspell\bin\aspell.exe

It can be best to install aspell in c:\aspell or use the 8.3 notation if you are installing in ''c:\program files'' so that the path looks like

c:\progra~1\aspell\bin\aspell.exe

*[[Configuring aspell on Mac OS X]]
*[[Configuring aspell on Windows 2003 Server]]

==External links==

*[http://aspell.sourceforge.net/ GNU Aspell]
*[http://aspell.net/win32/ GNU Aspell (Win32 version)]
*[http://sourceforge.net/project/showfiles.php?group_id=9328 Du, Zip and Unzip binaries for Win32]

==See also==

*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=28465 Check your aspell installation] forum discussion
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=41831 When will we be able to use TinyCME in Moodle?] forum discussion

[[Category:Administrator]]

Performance recommendations

2007-10-29T14:58:16Z

CHRISF: /* MySQL performance */

Location: ''Administration > Server > Performance''

Moodle can be made to perform very well, at small usage levels or scaling up to many thousands of users. The factors involved in performance are basically the same as for any PHP-based database-driven system. When trying to optimize your server, try to focus on the factor which will make the most difference to the user. For example, if you have relatively more users browsing than accessing the database, look to improve the webserver performance.

==Obtain a baseline benchmark==

Before attempting any optimization, you should obtain a baseline benchmark of the component of the system you are trying to improve. For Linux try [http://lbs.sourceforge.net/ LBS] and for Windows use the Performance Monitor. Once you have quantitative data about how your system is performing currently, you'll be able to determine if the change you have made as has any real impact.

The overall aim of adjustments to improve performance is to use RAM (cacheing) and to reduce disk-based activity. It is especially important to try to eliminate swap file usage as much as you can. If your system starts swapping, this is a sign that you need more RAM.

The '''optimization order preference''' is usually: primary storage (more RAM), secondary storage (faster hard disks/improved hard disk configuration), processor (more and faster).

==Scalability==

Moodle's design (with clear separation of application layers) allows for strongly scalable setups. (Please check the list of [[Large installations|large Moodle installations]].)

Large sites usually separate the web server and database onto separate servers, although for smaller installations this is typically not necessary.

It is possible to load-balance a Moodle installation, for example by using more than one webserver. The separate webservers should query the same database and refer to the same filestore area, but otherwise the separation of the application layers is complete enough to make this kind of clustering feasible. Similarly, the database could be a cluster of servers (e.g. a MySQL cluster), but this is not an easy task and you should seek expert support, e.g. from a Moodle Partner.

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

==Hardware configuration==
'''Note''': The fastest and most effective change that you can make to improve performance is to '''increase the amount of RAM on your web server''' - get as much as possible (eg 4GB). Increasing primary memory will reduce the need for processes to swap to disk and will enable your server to handle more users.
* Better performance is gained by obtaining the best '''processor capability''' you can, i.e. dual or dual core processors. A modern BIOS should allow you to enable hyperthreading, but check if this makes a difference to the overall performance of the processors by using a [http://en.wikipedia.org/wiki/Super_PI CPU benchmarking tool].
* If you can afford them, use '''SCSI hard disks''' instead of SATA drives. SATA drives will increase your system's CPU utilization, whereas SCSI drives have their own integrated processors and come into their own when you have multiple drives. If you must have SATA drives, check that your motherboard and the drives themselves support NCQ (Native Command Queuing).
* Purchase hard disks with a '''low seek time'''. This will improve the overall speed of your system, especially when accessing Moodle's reports.
* Size your '''swap file''' correctly. The general advice is to set it to 4 x physical RAM.
* Use a '''RAID disk system'''. Although there are many different RAID configurations you can create, the following generally works best:
** install a hardware RAID controller (if you can)
** the operating system and swap drive on one set of disks configured as RAID-1.
** Moodle, Web server and Database server on another set of disks configured as RAID-5.
* Use '''gigabit ethernet''' for improved latency and throughput. This is especially important when you have your webserver and database server separated out on different hosts.
* Check the settings on your '''network card'''. You may get an improvement in performance by increasing the use of buffers and transmit/receive descriptors (balance this with processor and memory overheads) and off-loading TCP checksum calculation onto the card instead of the OS.
* Read this Case Study on a server stress test with 300 users.[http://moodle.org/mod/forum/discuss.php?d=68579]
* See this accompanying report on network traffic and server loads. [http://elearning.sgu.ac.jp/doc/PT/]

==Operating System==
* You can use [http://en.wikipedia.org/wiki/Linux Linux](recommended), Unix-based, Windows or Mac OS X for the server '''operating system'''. *nix operating systems generally require less memory than Mac OS X or Windows servers for doing the same task as the server is configured with just a shell interface. Additionally Linux does not have licensing fees attached, but can have a big learning curve if you're used to another operating system. If you have a large number of processors running SMP, you may also want to consider using a highly tuned OS such as [http://en.wikipedia.org/wiki/Solaris_Operating_Environment Solaris].
* Check your own OS and '''vendor specific instructions''' for optimization steps.
** For Linux look at the [http://linuxperf.sourceforge.net/ Linux Performance Team] site.
** For Linux investigate the hdparm command, e.g. hdparm -m16 -d1 can be used to enable read/write on multiple sectors and DMA. Mount disks with the async and noatime options.
** For Windows set the sever to be optimized for network applications (Control Panel, Network Connections, LAN connection, Properties, File & Printer Sharing for Microsoft Networks, Properties, Optimization). You can also search the [http://technet.microsoft.com/ Microsoft TechNet site] for optimization documents.

==Web server performance==

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

===PHP performance===
* You are strongly recommended to use a '''PHP accelerator''' to ease CPU load, such as [http://pecl.php.net/apc APC] (recommended), [http://www.php-accelerator.co.uk/ PHPA], [http://trac.lighttpd.net/xcache/ Xcache] or [http://eaccelerator.net/ eAccelerator]. (Take care to choose a PHP accelerator that is known to work well with your version of PHP and note that Turck MMCache is [http://turckmmcache.exeprod.com/TheManifestoEnglish no longer maintained] and can cause failures with PHP 5). Put the cached PHP pages on a [[TMPFS]] filesystem.
* Performance of PHP is better when installed as an '''Apache/IIS ISAPI module''' (rather than a CGI).
* Also check the '''memory_limit''' in php.ini, reduce it to 16M for Moodle version earlier than 1.7 ([http://moodle.org/mod/forum/discuss.php?d=39656 See this forum discussion]). For Moodle 1.7 or later, it is recommended that the value of memory_limit should be 40M.

===Apache performance===
* Set the '''MaxClients''' directive correctly. Use this formula to help (which uses 80% of available memory to leave room for spare):
MaxClients = Total available memory * 80% / Max memory usage of apache process
:Memory usage of apache process is usually 10MB, so a general rule of thumb is to divide your available memory in megabytes by 10 to get the value of MaxClients. To find the max memory usage of apache processes read the value from the shell command:
#ps -ylC httpd --sort:rss
:'''Warning''': Do not be tempted to set the value of MaxClients higher than your available memory as your server will consume more RAM than available and start to swap to disk.
* Consider reducing the '''number of modules''' that Apache loads in the httpd.conf file to the minumum necessary to reduce the memory needed.
* Use the '''latest version of Apache''' - Apache 2 has an improved memory model which reduces memory usage further.
* For Unix/Linux systems, consider lowering '''MaxRequestsPerChild''' in httpd.conf to as low as 20-30 (if you set it any lower the overhead of forking begins to outweigh the benefits).
* For a heavily loaded server, consider setting '''KeepAlive Off''' (do this only if your Moodle pages do not contain links to resources or uploaded images) or lowering the '''KeepAliveTimeout''' to between 2 and 5. The default is 15 (seconds) - the higher the value the more server processes will be kept waiting for possibly idle connections. A more accurate value for KeepAliveTimeout is obtained by observing how long it takes your users to download a page. After altering any of the KeepAlive variables, monitor your CPU utilization as there may be an additional overhead in initiating more worker processes/threads.
* As an alternative to using KeepAlive Off, consider setting-up a '''Reverse Proxy server''' infront of the Moodle server to cache HTML files with images. You can then return Apache to using keep-alives on the Moodle server.
* If you do not use a .htaccess file, set the '''AllowOverride''' variable to AllowOverride None to prevent .htaccess lookups.
* Set '''DirectoryIndex''' correctly so as to avoid content-negotiation. Here's an example from a production server:
DirectoryIndex index.php index.html index.htm
* Unless you are doing development work on the server, set '''ExtendedStatus Off''' and disable mod_info as well as mod_status.
* Leave '''HostnamesLookups Off''' (as default) to reduce DNS latency.
* Consider reducing the value of '''TimeOut''' to between 30 to 60 (seconds).
* For the '''Options directive''', avoid Options Multiviews as this performs a directory scan. To reduce disk I/O further use
Options -Indexes FollowSymLinks
*'''Caching''' - Apache can be told to make pages load a lot faster by specifying that the browser should cache some various page elements such as images and reuse them from local memory rather than ask for them again every time a page is requested. How to do this varies slightly between OSes but there are two basic steps:

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

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

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

* Alternatively, you can increase web server performance by using the '''light-weight webserver''' [http://www.lighttpd.org/ lighttpd] in combination with PHP in fastCGI-mode instead of Apache. Lighttpd has a lower memory consumption than Apache. One single apache process requires more RAM than the whole lighttpd with all of its fastCGI-processes together. Note that Lighttpd is relatively difficult to configure and administration takes a more time.

===IIS performance===
All alter this location in the registry:
HKLM\SYSTEM\CurrentControlSet\Services\Inetinfo\Parameters\
* The equivalent to KeepAliveTimeout is '''ListenBackLog''' (IIS - registry location is HKLM\ SYSTEM\ CurrentControlSet\ Services\ Inetinfo\ Parameters). Set this to between 2 to 5.
*Change the '''MemCacheSize''' value to adjust the amount of memory (Mb) that IIS will use for its file cache (50% of available memory by default).
*Change the '''MaxCachedFileSize''' to adjust the maximum size of a file cached in the file cache in bytes. Default is 262,144 (256K).
*Create a new DWORD called '''ObjectCacheTTL''' to change the length of time (in milliseconds) that objects in the cache are held in memory. Default is 30,000 milliseconds (30 seconds).

==Database performance==

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

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

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

===MySQL performance===

The following are MySQL specific settings which can be adjusted for better performance in your my.cnf (my.ini in Windows). 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.
* Enable the '''query cache''' with query_cache_type = 1. For most Moodle installs, set the query_cache_size to 36M and query_cache_min_res_unit to 2K. The query cache will improve performance if you are doing few updates on the database.
* Set the '''table cache''' correctly. For Moodle 1.6 set table_cache = 256 (min), and for Moodle 1.7 set table_cache = 512 (min). The table cache is used by all threads (connections), so monitor the value of opened_tables to further adjust - if opened_tables > 3 * table_cache then increase table_cache upto your OS limit. Note also that the figure for table_cache will also change depending on the number of modules and plugins you have installed. Find the number for your server by executing the mysql statement below. Look at the number returned and set table_cache to this value.
mysql>SELECT COUNT(table_name) FROM information_schema.tables WHERE table_schema='yourmoodledbname';
* Set the '''thread cache''' correctly. Adjust the value so that your thread cache utilization is as close to 100% as possible by this formula:
thread cache utilization (%) = (threads_created / connections) * 100
* The '''key buffer''' can improve the access speed to Moodle's SELECT queries. The correct size depends on the size of the index files (.myi) and in Moodle 1.6 or later (without any additional modules and plugins), the recommendation for this value is key_buffer_size = 32M. Ideally you want the database to be reading once from the disk for every 100 requests so monitor that the value is suitable for your install by adjusting the value of key_buffer_size so that the following formulas are true:
key_read / key_read_requests < 0.01
key_write / key_write_requests <= 1.0
* Set the '''maximum number of connections''' so that your users will not see a "Too many connections" message. Be careful that this may have an impact on the total memory used. MySQL connections usually last for milliseconds, so it is unusual even for a heavily loaded server for this value to be over 200.
* Manage '''high burst activity'''. If your Moodle install uses a lot of quizzes and you are experiencing performance problems (check by monitoring the value of threads_connected - it should not be rising) consider increasing the value of back_log.
* '''Optimize your tables weekly and after upgrading Moodle'''. It is good practice to also optimize your tables after performing a large data deletion exercise, e.g. at the end of your semester or academic year. This will ensure that index files are up to date. Backup your database first and then use:
mysql>CHECK TABLE mdl_tablename;
mysql>OPTIMIZE TABLE mdl_tablename;
:The common tables in Moodle to check are mdl_course_sections, mdl_forum_posts, mdl_log and mdl_sessions (if using dbsessions). Any errors need to be corrected using REPAIR TABLE (see the [http://dev.mysql.com/doc/refman/5.0/en/repair-table.html MySQL manual] and this [http://moodle.org/mod/forum/discuss.php?d=58208#p279638 forum script]).
* '''Maintain the key distribution'''. Every month or so it is a good idea to stop the mysql server and run these myisamchk commands.
#myisamchk -a -S /pathtomysql/data/moodledir/*.MYI
:'''Warning''': You must stop the mysql database process (mysqld) before running any myisamchk command. If you do not, you risk data loss.
* Reduce the number of '''temporary tables saved to disk'''. Check this with the created_tmp_disk_tables value. If this is relatively large (>5%) increase tmp_table_size until you see a reduction. Note that this will have an impact on RAM usage.
* Moodle's tables are in the MyISAM format, so '''turn InnoDB off''' as there is no performance gain. Add <code>skip-innodb</code> to your <code>my.cnf</code> file. If you must use InnoDB, you'll have to convert all of Moodle's tables. To do this run the innodb script:

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

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

==Moodle Admin settings==
* In Moodle 1.7 or later, set the '''Cache type''' for your server: Site Admin -> Server -> Performance -> Cache type. There are several options available.
:*If you do not have eaccelerator or mmemcached installed, choose "internal" (which makes use of the record/internal cache - see the next bullet point).
:* If you have a single server and have compiled '''eaccelerator with shared memory support''', set the cache type to the eaccelerator option.
:* If you have a '''separate memcached server''', set the cache type to memcached and enter a csv list of server IP addresses.
* Enable the '''record/internal cache''': Site Admin -> Server -> Performance -> Record cache = True. Set the maximum amount of memory allocated to the cache in the Int Cache Max box. This will enable a primary cache for database records, without using any database engine cache, e.g. MySQL/PostgreSQL cache. See [http://tracker.moodle.org/browse/MDL-7196 this Tracker entry] for a full discussion.
* Enable the '''language cache'''.
* Large log files can cause overall performance to degrade over time. If you observe that the site has gradually got slower loading pages in the browser, '''reduce your Log life time''' setting (Admin/Server/Cleanup).
* Performance can be greatly improved by allowing Moodle to use the system '''zip/unzip''' commands (rather than PHP-based zip libraries) - visit Admin/Server/System Paths and enter the path to the relevant executables. (Similarly, filling in the path to '''du''' will improve Moodle's speed at listing directory contents.)
* Note that using '''secure web connections''' ('''https''' rather than '''http''') carries a higher processing burden, both for the webserver and the client - particularly because cacheing cannot be used as effectively, so the number of file requests is likely to increase dramatically. For this reason using https for all Moodle pages is not recommended. You can enable https just for the login screen, simply from Moodle's config page.
* Check your '''filters'''. Having too many filters active can have serious effects on server load, especially on lower-end systems. The number of active filters has a direct effect on the perceived latency of your site; that is the time taken for each page impression.
* Enable the '''text cache''' but do not "Filter all strings" unless you have a specific need. If in doubt profile the performance, and see how your changes affect the processing time.
* Check your '''anti-virus''' measures on the server. Although they are useful for preventing security holes being exploited, some "On-Demand" scanners can affect performance by scanning page content (word, ppt files etc).
* If there are performance problems loading course pages, check the '''Resource module settings'''. The setting resource_filterexternalpages is known to slow-down course pages and should be set to 'No' for better performance.
* Check your '''forum settings'''. To improve performance set forum_trackreadposts = No and forum_usermarksread = Yes (this will impact on the convenience of your users' forum experience). Also consider setting the time of the day when old posts are cleared from the read table (forum_cleanreadtime) to when your site is less busy.

==Performance of different Moodle modules==

Moodle's activity modules, filters, and other plugins can be activated/deactivated. If necessary, you may wish to deactivate some features (such as chat) if not required - but this isn't necessary. Some notes on the performance of certain modules:

* The '''Chat''' module is [http://moodle.org/mod/forum/discuss.php?d=37979&parent=175079 said] to be a hog in terms of frequent HTTP requests to the main server. This can be reduced by setting the module to use ''Streamed'' updates, or, if you're using a Unix-based webserver, by running the chat in daemon mode. When using the Chat module use the configuration settings to tune for your expected load. Pay particular attention to the ''chat_old_ping'' and ''chat_refresh'' parameters as these can have greatest impact on server load.
* The '''Quiz''' module is known to stretch database performance. Try to optimise your database server by tuning. See [http://moodle.org/mod/forum/discuss.php?d=25616&parent=120770 for a brief report on performance for 55 students simultaneously using quizzes]
** See this Case Study for an extensive server stress test with 300 quiz users.[http://moodle.org/mod/forum/discuss.php?d=68579] And this accompanying report on network traffic and server loads. [http://elearning.sgu.ac.jp/doc/PT/]
* The Moodle '''Cron''' task is triggered by calling the script ''cron.php''. If this is called over HTTP (e.g. using wget or curl) it can take a large amount of memory on large installations. If it is called by directly invoking the php command (e.g. ''php -f /path/to/moodle/directory/admin/cron.php'') efficiency can be much improved.

==See also==

*Using Moodle [http://moodle.org/mod/forum/view.php?f=94 Servers and Performance] forum
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=57028 Performance perspectives - a little script] forum discussion

[[Category:Performance]]

[[fr:Performance]]
[[ja:パフォーマンス]]

Performance recommendations

2007-10-29T14:57:41Z

CHRISF: /* MySQL performance */

Location: ''Administration > Server > Performance''

Moodle can be made to perform very well, at small usage levels or scaling up to many thousands of users. The factors involved in performance are basically the same as for any PHP-based database-driven system. When trying to optimize your server, try to focus on the factor which will make the most difference to the user. For example, if you have relatively more users browsing than accessing the database, look to improve the webserver performance.

==Obtain a baseline benchmark==

Before attempting any optimization, you should obtain a baseline benchmark of the component of the system you are trying to improve. For Linux try [http://lbs.sourceforge.net/ LBS] and for Windows use the Performance Monitor. Once you have quantitative data about how your system is performing currently, you'll be able to determine if the change you have made as has any real impact.

The overall aim of adjustments to improve performance is to use RAM (cacheing) and to reduce disk-based activity. It is especially important to try to eliminate swap file usage as much as you can. If your system starts swapping, this is a sign that you need more RAM.

The '''optimization order preference''' is usually: primary storage (more RAM), secondary storage (faster hard disks/improved hard disk configuration), processor (more and faster).

==Scalability==

Moodle's design (with clear separation of application layers) allows for strongly scalable setups. (Please check the list of [[Large installations|large Moodle installations]].)

Large sites usually separate the web server and database onto separate servers, although for smaller installations this is typically not necessary.

It is possible to load-balance a Moodle installation, for example by using more than one webserver. The separate webservers should query the same database and refer to the same filestore area, but otherwise the separation of the application layers is complete enough to make this kind of clustering feasible. Similarly, the database could be a cluster of servers (e.g. a MySQL cluster), but this is not an easy task and you should seek expert support, e.g. from a Moodle Partner.

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

==Hardware configuration==
'''Note''': The fastest and most effective change that you can make to improve performance is to '''increase the amount of RAM on your web server''' - get as much as possible (eg 4GB). Increasing primary memory will reduce the need for processes to swap to disk and will enable your server to handle more users.
* Better performance is gained by obtaining the best '''processor capability''' you can, i.e. dual or dual core processors. A modern BIOS should allow you to enable hyperthreading, but check if this makes a difference to the overall performance of the processors by using a [http://en.wikipedia.org/wiki/Super_PI CPU benchmarking tool].
* If you can afford them, use '''SCSI hard disks''' instead of SATA drives. SATA drives will increase your system's CPU utilization, whereas SCSI drives have their own integrated processors and come into their own when you have multiple drives. If you must have SATA drives, check that your motherboard and the drives themselves support NCQ (Native Command Queuing).
* Purchase hard disks with a '''low seek time'''. This will improve the overall speed of your system, especially when accessing Moodle's reports.
* Size your '''swap file''' correctly. The general advice is to set it to 4 x physical RAM.
* Use a '''RAID disk system'''. Although there are many different RAID configurations you can create, the following generally works best:
** install a hardware RAID controller (if you can)
** the operating system and swap drive on one set of disks configured as RAID-1.
** Moodle, Web server and Database server on another set of disks configured as RAID-5.
* Use '''gigabit ethernet''' for improved latency and throughput. This is especially important when you have your webserver and database server separated out on different hosts.
* Check the settings on your '''network card'''. You may get an improvement in performance by increasing the use of buffers and transmit/receive descriptors (balance this with processor and memory overheads) and off-loading TCP checksum calculation onto the card instead of the OS.
* Read this Case Study on a server stress test with 300 users.[http://moodle.org/mod/forum/discuss.php?d=68579]
* See this accompanying report on network traffic and server loads. [http://elearning.sgu.ac.jp/doc/PT/]

==Operating System==
* You can use [http://en.wikipedia.org/wiki/Linux Linux](recommended), Unix-based, Windows or Mac OS X for the server '''operating system'''. *nix operating systems generally require less memory than Mac OS X or Windows servers for doing the same task as the server is configured with just a shell interface. Additionally Linux does not have licensing fees attached, but can have a big learning curve if you're used to another operating system. If you have a large number of processors running SMP, you may also want to consider using a highly tuned OS such as [http://en.wikipedia.org/wiki/Solaris_Operating_Environment Solaris].
* Check your own OS and '''vendor specific instructions''' for optimization steps.
** For Linux look at the [http://linuxperf.sourceforge.net/ Linux Performance Team] site.
** For Linux investigate the hdparm command, e.g. hdparm -m16 -d1 can be used to enable read/write on multiple sectors and DMA. Mount disks with the async and noatime options.
** For Windows set the sever to be optimized for network applications (Control Panel, Network Connections, LAN connection, Properties, File & Printer Sharing for Microsoft Networks, Properties, Optimization). You can also search the [http://technet.microsoft.com/ Microsoft TechNet site] for optimization documents.

==Web server performance==

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

===PHP performance===
* You are strongly recommended to use a '''PHP accelerator''' to ease CPU load, such as [http://pecl.php.net/apc APC] (recommended), [http://www.php-accelerator.co.uk/ PHPA], [http://trac.lighttpd.net/xcache/ Xcache] or [http://eaccelerator.net/ eAccelerator]. (Take care to choose a PHP accelerator that is known to work well with your version of PHP and note that Turck MMCache is [http://turckmmcache.exeprod.com/TheManifestoEnglish no longer maintained] and can cause failures with PHP 5). Put the cached PHP pages on a [[TMPFS]] filesystem.
* Performance of PHP is better when installed as an '''Apache/IIS ISAPI module''' (rather than a CGI).
* Also check the '''memory_limit''' in php.ini, reduce it to 16M for Moodle version earlier than 1.7 ([http://moodle.org/mod/forum/discuss.php?d=39656 See this forum discussion]). For Moodle 1.7 or later, it is recommended that the value of memory_limit should be 40M.

===Apache performance===
* Set the '''MaxClients''' directive correctly. Use this formula to help (which uses 80% of available memory to leave room for spare):
MaxClients = Total available memory * 80% / Max memory usage of apache process
:Memory usage of apache process is usually 10MB, so a general rule of thumb is to divide your available memory in megabytes by 10 to get the value of MaxClients. To find the max memory usage of apache processes read the value from the shell command:
#ps -ylC httpd --sort:rss
:'''Warning''': Do not be tempted to set the value of MaxClients higher than your available memory as your server will consume more RAM than available and start to swap to disk.
* Consider reducing the '''number of modules''' that Apache loads in the httpd.conf file to the minumum necessary to reduce the memory needed.
* Use the '''latest version of Apache''' - Apache 2 has an improved memory model which reduces memory usage further.
* For Unix/Linux systems, consider lowering '''MaxRequestsPerChild''' in httpd.conf to as low as 20-30 (if you set it any lower the overhead of forking begins to outweigh the benefits).
* For a heavily loaded server, consider setting '''KeepAlive Off''' (do this only if your Moodle pages do not contain links to resources or uploaded images) or lowering the '''KeepAliveTimeout''' to between 2 and 5. The default is 15 (seconds) - the higher the value the more server processes will be kept waiting for possibly idle connections. A more accurate value for KeepAliveTimeout is obtained by observing how long it takes your users to download a page. After altering any of the KeepAlive variables, monitor your CPU utilization as there may be an additional overhead in initiating more worker processes/threads.
* As an alternative to using KeepAlive Off, consider setting-up a '''Reverse Proxy server''' infront of the Moodle server to cache HTML files with images. You can then return Apache to using keep-alives on the Moodle server.
* If you do not use a .htaccess file, set the '''AllowOverride''' variable to AllowOverride None to prevent .htaccess lookups.
* Set '''DirectoryIndex''' correctly so as to avoid content-negotiation. Here's an example from a production server:
DirectoryIndex index.php index.html index.htm
* Unless you are doing development work on the server, set '''ExtendedStatus Off''' and disable mod_info as well as mod_status.
* Leave '''HostnamesLookups Off''' (as default) to reduce DNS latency.
* Consider reducing the value of '''TimeOut''' to between 30 to 60 (seconds).
* For the '''Options directive''', avoid Options Multiviews as this performs a directory scan. To reduce disk I/O further use
Options -Indexes FollowSymLinks
*'''Caching''' - Apache can be told to make pages load a lot faster by specifying that the browser should cache some various page elements such as images and reuse them from local memory rather than ask for them again every time a page is requested. How to do this varies slightly between OSes but there are two basic steps:

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

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

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

* Alternatively, you can increase web server performance by using the '''light-weight webserver''' [http://www.lighttpd.org/ lighttpd] in combination with PHP in fastCGI-mode instead of Apache. Lighttpd has a lower memory consumption than Apache. One single apache process requires more RAM than the whole lighttpd with all of its fastCGI-processes together. Note that Lighttpd is relatively difficult to configure and administration takes a more time.

===IIS performance===
All alter this location in the registry:
HKLM\SYSTEM\CurrentControlSet\Services\Inetinfo\Parameters\
* The equivalent to KeepAliveTimeout is '''ListenBackLog''' (IIS - registry location is HKLM\ SYSTEM\ CurrentControlSet\ Services\ Inetinfo\ Parameters). Set this to between 2 to 5.
*Change the '''MemCacheSize''' value to adjust the amount of memory (Mb) that IIS will use for its file cache (50% of available memory by default).
*Change the '''MaxCachedFileSize''' to adjust the maximum size of a file cached in the file cache in bytes. Default is 262,144 (256K).
*Create a new DWORD called '''ObjectCacheTTL''' to change the length of time (in milliseconds) that objects in the cache are held in memory. Default is 30,000 milliseconds (30 seconds).

==Database performance==

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

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

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

===MySQL performance===

The following are MySQL specific settings which can be adjusted for better performance in your my.cnf (my.ini in Windows). 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.
* Enable the '''query cache''' with query_cache_type = 1. For most Moodle installs, set the query_cache_size to 36M and query_cache_min_res_unit to 2K. The query cache will improve performance if you are doing few updates on the database.
* Set the '''table cache''' correctly. For Moodle 1.6 set table_cache = 256 (min), and for Moodle 1.7 set table_cache = 512 (min). The table cache is used by all threads (connections), so monitor the value of opened_tables to further adjust - if opened_tables > 3 * table_cache then increase table_cache upto your OS limit. Note also that the figure for table_cache will also change depending on the number of modules and plugins you have installed. Find the number for your server by executing the mysql statement below. Look at the number returned and set table_cache to this value.
mysql>SELECT COUNT(table_name) FROM information_schema.tables WHERE table_schema='yourmoodledbname';
* Set the '''thread cache''' correctly. Adjust the value so that your thread cache utilization is as close to 100% as possible by this formula:
thread cache utilization (%) = (threads_created / connections) * 100
* The '''key buffer''' can improve the access speed to Moodle's SELECT queries. The correct size depends on the size of the index files (.myi) and in Moodle 1.6 or later (without any additional modules and plugins), the recommendation for this value is key_buffer_size = 32M. Ideally you want the database to be reading once from the disk for every 100 requests so monitor that the value is suitable for your install by adjusting the value of key_buffer_size so that the following formulas are true:
key_read / key_read_requests < 0.01
key_write / key_write_requests <= 1.0
* Set the '''maximum number of connections''' so that your users will not see a "Too many connections" message. Be careful that this may have an impact on the total memory used. MySQL connections usually last for milliseconds, so it is unusual even for a heavily loaded server for this value to be over 200.
* Manage '''high burst activity'''. If your Moodle install uses a lot of quizzes and you are experiencing performance problems (check by monitoring the value of threads_connected - it should not be rising) consider increasing the value of back_log.
* '''Optimize your tables weekly and after upgrading Moodle'''. It is good practice to also optimize your tables after performing a large data deletion exercise, e.g. at the end of your semester or academic year. This will ensure that index files are up to date. Backup your database first and then use:
mysql>CHECK TABLE mdl_tablename;
mysql>OPTIMIZE TABLE mdl_tablename;
:The common tables in Moodle to check are mdl_course_sections, mdl_forum_posts, mdl_log and mdl_sessions (if using dbsessions). Any errors need to be corrected using REPAIR TABLE (see the [http://dev.mysql.com/doc/refman/5.0/en/repair-table.html MySQL manual] and this [http://moodle.org/mod/forum/discuss.php?d=58208#p279638 forum script]).
* '''Maintain the key distribution'''. Every month or so it is a good idea to stop the mysql server and run these myisamchk commands.
#myisamchk -a -S /pathtomysql/data/moodledir/*.MYI
:'''Warning''': You must stop the mysql database process (mysqld) before running any myisamchk command. If you do not, you risk data loss.
* Reduce the number of '''temporary tables saved to disk'''. Check this with the created_tmp_disk_tables value. If this is relatively large (>5%) increase tmp_table_size until you see a reduction. Note that this will have an impact on RAM usage.
* Moodle's tables are in the MyISAM format, so '''turn InnoDB off''' as there is no performance gain. Add <code>skip-innodb</code to your <code>my.cnf</code> file. If you must use InnoDB, you'll have to convert all of Moodle's tables. To do this run the innodb script:

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

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

==Moodle Admin settings==
* In Moodle 1.7 or later, set the '''Cache type''' for your server: Site Admin -> Server -> Performance -> Cache type. There are several options available.
:*If you do not have eaccelerator or mmemcached installed, choose "internal" (which makes use of the record/internal cache - see the next bullet point).
:* If you have a single server and have compiled '''eaccelerator with shared memory support''', set the cache type to the eaccelerator option.
:* If you have a '''separate memcached server''', set the cache type to memcached and enter a csv list of server IP addresses.
* Enable the '''record/internal cache''': Site Admin -> Server -> Performance -> Record cache = True. Set the maximum amount of memory allocated to the cache in the Int Cache Max box. This will enable a primary cache for database records, without using any database engine cache, e.g. MySQL/PostgreSQL cache. See [http://tracker.moodle.org/browse/MDL-7196 this Tracker entry] for a full discussion.
* Enable the '''language cache'''.
* Large log files can cause overall performance to degrade over time. If you observe that the site has gradually got slower loading pages in the browser, '''reduce your Log life time''' setting (Admin/Server/Cleanup).
* Performance can be greatly improved by allowing Moodle to use the system '''zip/unzip''' commands (rather than PHP-based zip libraries) - visit Admin/Server/System Paths and enter the path to the relevant executables. (Similarly, filling in the path to '''du''' will improve Moodle's speed at listing directory contents.)
* Note that using '''secure web connections''' ('''https''' rather than '''http''') carries a higher processing burden, both for the webserver and the client - particularly because cacheing cannot be used as effectively, so the number of file requests is likely to increase dramatically. For this reason using https for all Moodle pages is not recommended. You can enable https just for the login screen, simply from Moodle's config page.
* Check your '''filters'''. Having too many filters active can have serious effects on server load, especially on lower-end systems. The number of active filters has a direct effect on the perceived latency of your site; that is the time taken for each page impression.
* Enable the '''text cache''' but do not "Filter all strings" unless you have a specific need. If in doubt profile the performance, and see how your changes affect the processing time.
* Check your '''anti-virus''' measures on the server. Although they are useful for preventing security holes being exploited, some "On-Demand" scanners can affect performance by scanning page content (word, ppt files etc).
* If there are performance problems loading course pages, check the '''Resource module settings'''. The setting resource_filterexternalpages is known to slow-down course pages and should be set to 'No' for better performance.
* Check your '''forum settings'''. To improve performance set forum_trackreadposts = No and forum_usermarksread = Yes (this will impact on the convenience of your users' forum experience). Also consider setting the time of the day when old posts are cleared from the read table (forum_cleanreadtime) to when your site is less busy.

==Performance of different Moodle modules==

Moodle's activity modules, filters, and other plugins can be activated/deactivated. If necessary, you may wish to deactivate some features (such as chat) if not required - but this isn't necessary. Some notes on the performance of certain modules:

* The '''Chat''' module is [http://moodle.org/mod/forum/discuss.php?d=37979&parent=175079 said] to be a hog in terms of frequent HTTP requests to the main server. This can be reduced by setting the module to use ''Streamed'' updates, or, if you're using a Unix-based webserver, by running the chat in daemon mode. When using the Chat module use the configuration settings to tune for your expected load. Pay particular attention to the ''chat_old_ping'' and ''chat_refresh'' parameters as these can have greatest impact on server load.
* The '''Quiz''' module is known to stretch database performance. Try to optimise your database server by tuning. See [http://moodle.org/mod/forum/discuss.php?d=25616&parent=120770 for a brief report on performance for 55 students simultaneously using quizzes]
** See this Case Study for an extensive server stress test with 300 quiz users.[http://moodle.org/mod/forum/discuss.php?d=68579] And this accompanying report on network traffic and server loads. [http://elearning.sgu.ac.jp/doc/PT/]
* The Moodle '''Cron''' task is triggered by calling the script ''cron.php''. If this is called over HTTP (e.g. using wget or curl) it can take a large amount of memory on large installations. If it is called by directly invoking the php command (e.g. ''php -f /path/to/moodle/directory/admin/cron.php'') efficiency can be much improved.

==See also==

*Using Moodle [http://moodle.org/mod/forum/view.php?f=94 Servers and Performance] forum
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=57028 Performance perspectives - a little script] forum discussion

[[Category:Performance]]

[[fr:Performance]]
[[ja:パフォーマンス]]

Adminer

2007-08-06T12:03:52Z

CHRISF: corrected link

MySQL Admin or '''phpMyAdmin''' is a useful [[MySQL]] database administration tool. It may be downloaded from the [http://moodle.org/mod/data/view.php?d=13&rid=448 Modules and plugins database].

==See also==

*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=56636 Remove database access] forum discussion

{{stub}}
[[Category:Administrator]]
[[Category:SQL database]]

User:Chris Fryer

2007-07-25T09:22:02Z

CHRISF:

Systems administrator at the [http://clt.lse.ac.uk/ Centre for Learning Technology], London School of Economics.

Backup restore

2007-03-07T11:22:06Z

CHRISF: /* Restore */

Moodle has a course backup and restore process. Each successive version of Moodle has offered more options in this process. Many Moodle site administrators turn on an automated backup function, which does a full course backup on a schedule. The on demand backup and restore functions can be found in the administrative block of a course.

An administrator or teacher with course creator privileges can use the backup restore functions to create, transfer or restore parts of an existing course or a whole course.

In this document we will use a Version 1.6 process.
{{Moodle 1.6}}

==Backup==
[[Image:Backup icon link.JPG]]Selecting backup icon, will give the user with the correct privilages 3 screens.
*Screen 1: Provides options to select which activities and resources should be backed up. This screen also includes an option to include student data for each of these activities and resources. The bottom of screen 1 asks how to handled meta courses, users, log files, user files and course files. The continue button starts the backup process.

*Screen 2 suggests a name for the backup file, which can be edited, informs the user what is actually going to be backed up. For example, the number of users and course files and which modules.

*Screen 3 reports if it was successful and has a continue button.

==Restore==
[[Image:Restore icon link.JPG]]Selecting the restore icon, will give show a list of files which can be restored in the backup directory. Select the file by clicking on restore link.

*Screen 1- confirms the file you selected to restore and asks if you want to continue or cancel
*Screen 2 - shows what is available in the file you have selected to restore
*Screen 3 - gives many options for restoring.
** Restore to option: new course, copy over a course or add to a course.
** Individual activity options: check off those parts of the course to be restored
***inclues option to restore student data for each part
** Restore course files option - these are image or resource files
*Screen 4 - Restore this course now button
*Screen 5 - Reports on what was successfully restored

==Notes ==
*Administrators and Course Creators options are:
**Restore to an existing course either adding to the course (keeping existing data) or deleting all existing data; or
**The creation of a new course using the data in the backup file being restored.
*Editing Teachers options are:
**Restore to an existing course either adding to the course (keeping existing data) or deleting all existing data.

==Restoring Moodle 1.6 and older courses to Moodle 1.7==
{{Moodle 1.7}}
The procedure of restoring a 1.6 or older course to a 1.7 site requires additional role mapping information to be entered (on Screen 3). Since Moodle 1.7 has a dynamic roles system, it is possible to map the old roles (i.e. editing teachers, non-editing teachers and students) onto any new roles. By default, Moodle 1.7 looks for legacy roles to map intelligently, for example Moodle 1.7 will map 1.6 students onto a 1.7 legacy student role. The roles you can map onto is determined by what you can assign in the current context (current course or site). For example, if you have the teacher role in a 1.7 course, you will not be able to map students onto admins in the restored course. There is also an option to create new roles to map onto.

==Restoring Moodle 1.7 courses to Moodle 1.7==
{{Moodle 1.7}}
This works pretty much the same, except there is role mapping information (on Screen 3). For every role in the backup course, you may select a corresponding role to map onto. By default, Moodle 1.7 compares the role shortname string and pre-selects the same for you. As a result, if you are restoring in the same site, you don't have to worry about what roles to map onto. The roles you can map onto are determined by what you can assign in the current context (current course or site). For example, if you have the teacher role in a 1.7 course, you will not be able to map students onto admins in the restored course. There is also an option to create new roles to map onto.

==See also==
*[[Restore]] how to restore a backup of a course
*[[Roll courses forward]], how to repeat a course again
*[[Import course data]] from you other courses. 1.6 feature in Moodle
[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Backup]]

[[ja:バックアップリストア]]

Forum settings

2006-01-17T12:17:17Z

CHRISF: /* Creating a new forum */

{{Forums}}

==Creating a new forum==

In your course, click "Turn Editing On", and go to the topic in which you want to create the forum. From the drop-down list labeled "Add an activity", select "Forum". This will take you to "Adding a new forum".

==Forum name==

A short name of the forum (e.g. "Favourite colour"), which will be displayed on the course homepage.

==Forum type==

For now, there are three forum types to choose from:

# '''A single simple discussion''' - a single topic discussion developed on one page, which is useful for short focussed discussions
# '''Standard forum for general use''' - an open forum where anyone can start a new topic at any time; this is the best general-purpose forum
# '''Each person posts one discussion''' - each person can post exactly one new discussion topic (everyone can reply to them though); this is useful when you want each student to start a discussion about, say, their reflections on the week's topic, and everyone else responds to these

==Forum introduction==

Type the description of the forum here. Include precise instructions for students regarding the subject of the forum and, if necessary, the grading criteria.

==Can a student post to this forum?==

This option allows you to restrict students from posting new content in this forum. Again you have three options to choose from:

# '''Discussions and replies are allowed''' This option leaves students unrestricted, which is the case for most forums. Thus, you choose to allow them to start new discussion topics (threads), and also to post replies within those threads.
# '''No discussions, but replies are allowed''' This option should be chosen the option if only teachers are to be allowed to start new discussions. Students will still be allowed to reply within those threads (for example within the news forum on the site home page).
# '''No discussions, no replies''' Choosing this option babs students from starting new discussion topics and replying within those threads. This is useful for the News forum when you only want teachers to post new items that appear on the course main page.

==Force everyone to be subscribed?==

When a person is subscribed to a forum it means that they will be sent email copies of every post in that forum (posts are sent about 30 minutes after the post was first written).

People can usually choose whether or not they want to be subscribed to each forum.

However, if you choose to force subscription on a particular forum then all course users will be subscribed automatically, even those that enrol at a later time.

This is especially useful in the News forum and in forums towards the beginning of the course (before everyone has worked out that they can subscribe to these emails themselves).

If you choose the option "Yes, initially" then all current and future course users will be subscribed initially but they can unsubscribe themselves at any time. If you choose "Yes, forever" then they will not be able to unsubscribe themselves.

Note how the "Yes, initially" option behaves when you update an existing forum: Changing from "Yes, initially" to "No" will not unsubscribe existing users, it will only affect future course users. Similarly changing later to "Yes, initially" will not subscribe existing course users but only those enrolling later.

==Read tracking for this forum?==

If 'read tracking' for forums is enabled, users can track read and unread messages in forums and discussions. The instructor can choose to force a tracking type on a forum using this setting.

There are three choice for this setting:

# '''Optional [default]''' - students can turn tracking on or off for the forum at their discretion
# '''On''' - tracking is always on
# '''Off''' - tracking is always off

==Maximum attachment size==

Attachments can be limited to a certain size file, chosen by the person who set up the forum.

Sometimes it is possible to upload a file larger than this size, but the file will not be saved on the server and you might see an error.

==Allow posts to be rated?==

Here you will have to consider whether or not enable two options:

====Use ratings====

If you decide to rate posts on the forum, you will have to define settings of the three following aspects:

* '''Users'''

If you want everybody to rate posts, choose 'Everyone can rate posts'. Otherwise, pick 'Only teachers can rate posts'.

* '''View'''

If you want to keep the grades known only to the individual students graded, you should choose the option 'Students can only see their own ratings'. If there is no such a need, opt for 'Students can see everyone's ratings'.

* '''Grade'''

There are several grading scales you can choose from. You can give a number of points to each post (from 1 to 100) or you can opt for two other scales: '''Scale: satisfactory''' (Outstanding, Satisfactory and Not satisfactory) or '''Separate and Connected ways of knowing''' (Mostly Connected Knowing, Separate and Connected, Mostly Separate Knowing). More information about the latter one are to be found [[Separate and Connected ways of knowing|here]].

====Restrict ratings to posts with dates in this range====

If you enable the '''Use ratings''' option, you will also face the necessity of choosing whether or not enable another option restricting ratings to posts in terms of time.

==Visible to students==

You can hide the activity from students by selecting "Hide" here. It is useful if you wouldn't like to make the activity available immediately.

[[Category:Teacher]]

Forum settings

2006-01-17T12:13:42Z

CHRISF:

{{Forums}}

==Creating a new forum==

In your course, turn editing on. In the topic where you want to create your forum, select "Forum" from the "Add an activity" drop-down list.

==Forum name==

A short name of the forum (e.g. "Favourite colour"), which will be displayed on the course homepage.

==Forum type==

For now, there are three forum types to choose from:

# '''A single simple discussion''' - a single topic discussion developed on one page, which is useful for short focussed discussions
# '''Standard forum for general use''' - an open forum where anyone can start a new topic at any time; this is the best general-purpose forum
# '''Each person posts one discussion''' - each person can post exactly one new discussion topic (everyone can reply to them though); this is useful when you want each student to start a discussion about, say, their reflections on the week's topic, and everyone else responds to these

==Forum introduction==

Type the description of the forum here. Include precise instructions for students regarding the subject of the forum and, if necessary, the grading criteria.

==Can a student post to this forum?==

This option allows you to restrict students from posting new content in this forum. Again you have three options to choose from:

# '''Discussions and replies are allowed''' This option leaves students unrestricted, which is the case for most forums. Thus, you choose to allow them to start new discussion topics (threads), and also to post replies within those threads.
# '''No discussions, but replies are allowed''' This option should be chosen the option if only teachers are to be allowed to start new discussions. Students will still be allowed to reply within those threads (for example within the news forum on the site home page).
# '''No discussions, no replies''' Choosing this option babs students from starting new discussion topics and replying within those threads. This is useful for the News forum when you only want teachers to post new items that appear on the course main page.

==Force everyone to be subscribed?==

When a person is subscribed to a forum it means that they will be sent email copies of every post in that forum (posts are sent about 30 minutes after the post was first written).

People can usually choose whether or not they want to be subscribed to each forum.

However, if you choose to force subscription on a particular forum then all course users will be subscribed automatically, even those that enrol at a later time.

This is especially useful in the News forum and in forums towards the beginning of the course (before everyone has worked out that they can subscribe to these emails themselves).

If you choose the option "Yes, initially" then all current and future course users will be subscribed initially but they can unsubscribe themselves at any time. If you choose "Yes, forever" then they will not be able to unsubscribe themselves.

Note how the "Yes, initially" option behaves when you update an existing forum: Changing from "Yes, initially" to "No" will not unsubscribe existing users, it will only affect future course users. Similarly changing later to "Yes, initially" will not subscribe existing course users but only those enrolling later.

==Read tracking for this forum?==

If 'read tracking' for forums is enabled, users can track read and unread messages in forums and discussions. The instructor can choose to force a tracking type on a forum using this setting.

There are three choice for this setting:

# '''Optional [default]''' - students can turn tracking on or off for the forum at their discretion
# '''On''' - tracking is always on
# '''Off''' - tracking is always off

==Maximum attachment size==

Attachments can be limited to a certain size file, chosen by the person who set up the forum.

Sometimes it is possible to upload a file larger than this size, but the file will not be saved on the server and you might see an error.

==Allow posts to be rated?==

Here you will have to consider whether or not enable two options:

====Use ratings====

If you decide to rate posts on the forum, you will have to define settings of the three following aspects:

* '''Users'''

If you want everybody to rate posts, choose 'Everyone can rate posts'. Otherwise, pick 'Only teachers can rate posts'.

* '''View'''

If you want to keep the grades known only to the individual students graded, you should choose the option 'Students can only see their own ratings'. If there is no such a need, opt for 'Students can see everyone's ratings'.

* '''Grade'''

There are several grading scales you can choose from. You can give a number of points to each post (from 1 to 100) or you can opt for two other scales: '''Scale: satisfactory''' (Outstanding, Satisfactory and Not satisfactory) or '''Separate and Connected ways of knowing''' (Mostly Connected Knowing, Separate and Connected, Mostly Separate Knowing). More information about the latter one are to be found [[Separate and Connected ways of knowing|here]].

====Restrict ratings to posts with dates in this range====

If you enable the '''Use ratings''' option, you will also face the necessity of choosing whether or not enable another option restricting ratings to posts in terms of time.

==Visible to students==

You can hide the activity from students by selecting "Hide" here. It is useful if you wouldn't like to make the activity available immediately.

[[Category:Teacher]]