Difference between revisions of "Caching"

Jump to: navigation, search

Note: You are currently viewing documentation for Moodle 2.5. Up-to-date documentation for the latest stable version of Moodle may be available here: Caching.

Line 1: Line 1:
 
{{Performance}}{{New features}}
 
{{Performance}}{{New features}}
A cache is a collection of data that is kept on hand and made readily available in order to avoid costly fetching and moulding upon every request.
 
  
Moodle 2.4 saw the implementation of MUC Stage 1: Implement some core caching architecture.
+
A cache is a collection of processed data that is kept on hand and re-used in order to avoid costly repeated database queries.
  
Two links, that might be useful to anyone considering testing the new features on their own servers:
+
Moodle 2.4 saw the implementation of MUC, the Moodle Universal Cache.  This new system allows certain functions of Moodle (eg string fetching) take advantage of different installed cache services (eg files, ram, memcached).
 +
 
 +
In future versions of Moodle we will continue expanding the number of Moodle functions that use MUC, which will continue improving performance, but you can already start using it to improve your site.
 +
 
 +
==General approach to performance testing==
 +
 
 +
Here is the general strategy you should be taking:
 +
 
 +
# Build a test environment that is as close to your real production instance as possible (eg hardware, software, networking, etc)
 +
# Make sure to remove as many uncontrolled variables as you can from this environment (eg other services)
 +
# Use a tool to place a realistic, but simulated and repeatable load upon you server. (eg jmeter or selenium).
 +
# Decide on a way to measure performance of the server by capturing data (ram, load, time taken, etc)
 +
# Run your load and measure a baseline performance result.
 +
# Change one variable at a time, and re-run the load to see if performance gets better or worse.  Repeat as necessary.
 +
# When you discover settings that result in a consistent performance improvement, apply to your production site.
 +
 
 +
==How to use the caching settings==
 +
 
 +
(to be written)
 +
 
 +
 
 +
 
 +
==Other performance testing==
 +
 
 +
Two links that might be useful to anyone considering testing performance on their own servers:
  
 
* [http://www.iteachwithmoodle.com/2012/10/12/moodle-performance-testing-how-much-more-horsepower-do-each-new-versions-of-moodle-require/ Moodle performance testing: how much more horsepower do each new versions of Moodle require?]
 
* [http://www.iteachwithmoodle.com/2012/10/12/moodle-performance-testing-how-much-more-horsepower-do-each-new-versions-of-moodle-require/ Moodle performance testing: how much more horsepower do each new versions of Moodle require?]

Revision as of 09:01, 11 December 2012

New feature
in Moodle 2.5!


A cache is a collection of processed data that is kept on hand and re-used in order to avoid costly repeated database queries.

Moodle 2.4 saw the implementation of MUC, the Moodle Universal Cache. This new system allows certain functions of Moodle (eg string fetching) take advantage of different installed cache services (eg files, ram, memcached).

In future versions of Moodle we will continue expanding the number of Moodle functions that use MUC, which will continue improving performance, but you can already start using it to improve your site.

General approach to performance testing

Here is the general strategy you should be taking:

  1. Build a test environment that is as close to your real production instance as possible (eg hardware, software, networking, etc)
  2. Make sure to remove as many uncontrolled variables as you can from this environment (eg other services)
  3. Use a tool to place a realistic, but simulated and repeatable load upon you server. (eg jmeter or selenium).
  4. Decide on a way to measure performance of the server by capturing data (ram, load, time taken, etc)
  5. Run your load and measure a baseline performance result.
  6. Change one variable at a time, and re-run the load to see if performance gets better or worse. Repeat as necessary.
  7. When you discover settings that result in a consistent performance improvement, apply to your production site.

How to use the caching settings

(to be written)


Other performance testing

Two links that might be useful to anyone considering testing performance on their own servers:

See also

Developer documentation: