Migrate CacheAPI #686 #687
Conversation
✅ Deploy Preview for moodledevdocs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Hi @tabishnaqvi1311!
Thanks for migrating this page. I've raised a few things that should be reviewed/improved before merging it :-)
Let me know if there is anything I can do for helping you ;-)
docs/apis/subsystems/muc/index.md
Outdated
|
|
||
| This is especially important if you are scaling up and down the number of frontends quickly. If you suddenly need more horizontal scale and create a bunch of new front ends with empty caches and no shared cache they will all consume even more resources warming up and loading the shared services such as the database and filesystem. | ||
|
|
||
| A good rule of thumb is to pair similar types of local and shared caches together. For instance it is very common to store the Moodle string cache in APCu because it is very heavily used, so an in-memory cache is the fastest and is well paired this a shared cache like Redis. coursemodinfo on the other hand is often very large so isn't as practical to store in Redis so it is usually cached on disk, so you could have a local file cache (which could often be very fast SSD) and pair it with a shared disk cache in dataroot (often much slower over NFS or Gluster etc). |
There was a problem hiding this comment.
| A good rule of thumb is to pair similar types of local and shared caches together. For instance it is very common to store the Moodle string cache in APCu because it is very heavily used, so an in-memory cache is the fastest and is well paired this a shared cache like Redis. coursemodinfo on the other hand is often very large so isn't as practical to store in Redis so it is usually cached on disk, so you could have a local file cache (which could often be very fast SSD) and pair it with a shared disk cache in dataroot (often much slower over NFS or Gluster etc). | |
| A good rule of thumb is to pair similar types of local and shared caches together. For instance, it is very common to store the Moodle string cache in APCu because it is very heavily used, so an in-memory cache is the fastest and is well paired this a shared cache like Redis. `coursemodinfo` on the other hand is often very large so isn't as practical to store in Redis so it is usually cached on disk, so you could have a local file cache (which could often be very fast `SSD`) and pair it with a shared disk cache in `dataroot` (often much slower over `NFS` or `Gluster` etc). |
docs/apis/subsystems/muc/index.md
Outdated
|
|
||
| Another consideration is the total size of your cache stores across all the front ends. As cache keys change they are never be invalidated or purged. So you should have in place some process to garbage collect stale items. This is more a concern for the cache store implementations and the configuration but worth considering. Some stores are deleted on upgrade, or have a Time-To-Live or a Least Recently Used strategy for deleting stale items. | ||
|
|
||
| ## Using a data source |
There was a problem hiding this comment.
| ## Using a data source |
docs/apis/subsystems/muc/index.md
Outdated
| Another consideration is the total size of your cache stores across all the front ends. As cache keys change they are never be invalidated or purged. So you should have in place some process to garbage collect stale items. This is more a concern for the cache store implementations and the configuration but worth considering. Some stores are deleted on upgrade, or have a Time-To-Live or a Least Recently Used strategy for deleting stale items. | ||
|
|
||
| ## Using a data source | ||
|
|
docs/apis/subsystems/muc/index.md
Outdated
|
|
||
| ## Using a data source | ||
|
|
||
| ## Developing cache plugins |
There was a problem hiding this comment.
| ## Developing cache plugins |
docs/apis/subsystems/muc/index.md
Outdated
| ## Using a data source | ||
|
|
||
| ## Developing cache plugins | ||
|
|
|
Hey @sarjona, thanks for your suggesting changes, they seem rather reasonable and I appreciate it! I have a question though, should I commit each of your suggestions individually? I'm wondering if that will create separate commits for each change. I'm still finding my way around open source, so your guidance means a ton. |
|
Hi @tabishnaqvi1311! Thanks a lot for the quick reply :-) Let me know if you need anything from me and post a comment when you finish reviewing the raised points :-) |
Co-authored-by: Sara Arjona <[email protected]>
sarjona
force-pushed
the
cache_api_migration
branch
from
920e9f3
to
fac4371
Compare
⚡️ Lighthouse report for the deploy preview of this PR
|
There was a problem hiding this comment.
I've amended the missing points and I've just approved it :-)
Thanks for your work here, @tabishnaqvi1311 :-*
No description provided.