I'm curious if anyone else has approached the issue of serving the MUC config file out of a non shared directory on a cluster of webservers?
Right now there are two read's to sitedata per every moodle connection, one to see if the sitedata exists and is writeable and the other to load the MUC config from the sitedata, this can be problematic if you're having latency issues with your underlying storage medium, as it turns slow filestores into what are essentially site outages.
Given that we already know our target cache configuration, as it's the same across the cluster, and we are generating it on deploy and have no operational reason to modify it after that point.
It would stand to reason then that you can simply use the altcacheconfigpath setting to have a webserver local file and simply disable modifying the cache configuration from the web interface.
I'm curious if anyone else out there has experimented with this approach and if there are any core developers who can give insight to any more circumstances that might lead to the cache config file needing to be shared? (In my head, this file is written only when the configuration actually changes, so given our use case - set on every deploy and not changed) this should not be an issue.
The reason that the file is shared is to ensure that all nodes in the cluster share the same configuration.
In 'normal' installations, it is written at other times too (plugin installation, and I think version bumps), but if you have a fully configuration-managed setup and are sure there will be no changes to the configuration then it should be safe to do so.
Hi Andrew, thanks for the reply and information.
In all cases where there would be a plugin installed, or a version upgrade, we are rebuilding the configuration file at that point anyway as part of the deployment process for updated code so in theory they should be covered.
The cases that will catch out here would be if the config file is rebuilt in relation to some non version/code change event