aharjula
commented
2 years ago Anyone willing to explore this is free to write a replacement connector class that does these things and simply let it employ whatever caching logic one wants in it and disable the normal DB cache. However, having spent some time with large caches and remembering the times of STACK 2 when we really had issues with caching, it is hard for me to see the current caching as a real issue. So I am not going to be the one that would explore this further.
While I would also like to have some TTL tracking, I have yet to see a STACK installation of such a scale that clearing the cache between yearly updates would have been necessary. Larger installations, after all, have larger and beefier databases and having tens (in any case less than hundreds) of millions of cache rows in that database is not an issue in those cases. Obviously, having multiple copies does mean duplication, and that is always annoying but is it of such a scale that it is worth exploring it in any detail, to me it seems like a thing that I would have explored 10 years ago, but in the current world where we have space and bandwidth available as a much simpler solution related to building separate fine-tuned caching configurations it does not make much sense to me.
That said, I do still install POST caching in my NGinx load-balancer that spreads the load to my MaximaPool nodes and use that instead of the DB-cache in some installations. It works with multiple STACK versions but does not really work if one would load different libraries. It does indeed lessen the load of the main Moodle DB and does, in some sense, provide TTL like behaviour. but it does not necessarily provide a major performance improvement (depends on the bandwidth available and the topology of the whole setup and so on).
sangwinc
In the past, many institutions set up additional installations of learning management systems (LMS) for exam purposes. As many questions are simply imported from the main LMS to the exam LMS, there is some (possibly lots) redundancy in the CAS cache on these systems.
While it would be possible to employ a query cache on the webserver a backend solution (e.g. MaximaPool) is running on, this might be undesirable for various reasons (cache persistence, pooling of nodes, etc.) and another solution might be more desirable.
We propose the possibility of specifying an external database / cache in the options, similar to those implemented in the Moodle cache administration ( cache/admin.php ).
This could be any of the cache stores implemented there (e.g. Redis - anything that offers persistence) or another database entirely with credentials, host:port, database & table names.
The benefits of this would be:
However, the following drawbacks need to be considered:
Please feel free to add any benefits / drawbacks to these or address ways how to deal with the latter.