You can use caching to improve the performance of your site. This page will explore some of the ways you might do this within Totara. You might also want to look at our Caching documentation for guides on how to configure caching in Totara.
When trying to understand caching in Totara there are some key terms and concepts you will need to understand as system administrator or developer. These are set out in more detail on this page.
For low-level "how to use caching in code," see https://moodledev.io/docs/apis/subsystems/muc instead. Totara's caching subsystem works the same way as Moodle's.
Cache modes
There are three cache modes within Totara.
Application caches: Used to store data available across sessions
Session caches: Used to store data specific to the user within their session
Request caches: Used to store data just for the lifetime of the request
Cache definitions
The cache definitions displayed on the interface show what areas Totara is caching data for, what mode is being used, and where the data for each definition is being stored.
Cache stores
Totara supports storing data in different locations out of the box, including the file system, memcached, and redis. Cache stores are also pluggable. Multiple stores can be configured on a single site.
Configuring caching within Totara
Caching is configurable at two levels, application caches and session caches.
...
Choosing an alternative cache store to use as the default, or choosing to map specific high load caches to better suited stores should be looked into for large installations.
Evaluating your caching configuration
There is no quick answer to this unfortunately.
Within Totara you can enable the display of performance information on each page page (Quick-access menu > Development > Debugging > perfdebug) which reveals which caches are being used on a particular page, and how many hits, misses and sets are occurring. However, to understand where bottlenecks are you will want to investigate how your current cache stores are performing, and test alternative stores and configurations.
In understanding bottlenecks you will want to focus your attention on the cache stores themselves. If you are using the default application cache this means monitoring the site data directory file system. You want to understand the bottlenecks of your chosen file system, and whether you are pushing against those limitations. You will also want to understand the overhead of communication between the application and your file system, this includes network latency and any potential lock and wait situations that may arise when the file system is under load.
Some ideas for testing alternative stores and configurations
Totara has a built in tool for measuring cache store performance at a basic level, which can be found at Quick-access menu > Plugins > Caching > Test performance. This should not be run on a production site as it will lead to the cache being load tested and will impact performance in itself.
...
We would also suggest targeted planning as not all caches are equal. Some caches are read heavy, others are write heavy. Some must use shared space (by default) while others are safe to be used on local storage. Investigating and understanding how caches are used on your site will enable you to better plan, theoretically, where they are best stored. See hints for cache consideration below for some ideas.
Hints and tips
Whether you have a single web server or have scaled horizontally has a biggest impact on how your are best to configure caching.
...