Hi Dileep,
By default the localization cache (https://www.mediawiki.org/wiki/Manual:LocalisationCache.php) is stored in the l10n_cache table, so it's all in the database. All replicas access the same cache. So, not only is it possible for multiple MediaWiki instances to share the same common L10n cache, but it is actually the default. If you are running many replicas, there might be some contention on a single database table causing some performance issues, so you can set it to a filesystem directory with $wgCacheDirectoy. Read more about this setting at https://www.mediawiki.org/wiki/Manual:$wgCacheDirectory.
I wouldn't prematurely optimize for what is worth, it's quite probable the default will take you a long way before alternatives are needed. When you find yourself at that spot, you will want to have each replica hold its own cache anyways, thus avoiding a centralized approach's issues. Each replica will be seeing enough requests to benefit from the per replica cache by that point.
On Tue, Sep 24, 2024 at 10:45 AM Dileep Kumar Paladugu dileep.paladugu@hallowelt.com wrote:
I'm new to MediaWiki and currently exploring caching strategies to improve the performance of my wiki setup. Specifically, I have a scenario where MediaWiki is deployed in Kubernetes with multiple replicas running simultaneously.
I would appreciate any insights or best practices for managing caching in this environment, especially when it comes to the localisation (L10N) cache.
I have a few specific questions:
Apart from upgrades and extension changes, are there any other scenarios where the localisation cache changes? Is it possible for multiple MediaWiki instances (with the same codebase) to share a common L10N cache? What are the recommended strategies for handling caching in a multiple replica setup?Thank you in advance for your help! _______________________________________________ Kubernetes-sig mailing list -- kubernetes-sig@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/kubernetes-sig.lists.wikimedia.o...