Realistically, this is probably not ready for shell keyword: $wgMiserMode does too many things, and [the absence of] all of them would be concentrated on a single database (s3) for all ~540 such wikis.

CCing Sean for a comment on the database load and viability of this.

With Nemo on this. It would have an unknown impact on S3, and switching back to doing everything dynamically is a recipe for surprises.

We probably need to apply finer grained controls than wgMiserMode, or disable it based on a /much/ shorter list that small.dblist, or increase the frequency of cache refreshes. I favour the last option.

I guess the step up is to go from doing it once a month like we do currently to twice a month?

https://github.com/wikimedia/operations-puppet/blob/production/manifests/misc/maintenance.pp

Seems like a fair increase.

(In reply to Sean Pringle from comment #3)

With Nemo on this. It would have an unknown impact on S3, and switching back
to doing everything dynamically is a recipe for surprises.

"Everything" is a bit broad. :-) I looked through mediawiki/core.git and $wgMiserMode is used primarily with a few API modules and Special pages. Most Wikimedia wikis are pretty small, so I'm not sure I understand the real concern here. (And, broadly, $wgMiserMode is actually used a lot less than I would've thought.)

Part of the point of creating https://noc.wikimedia.org/conf/small.dblist was to be able to disable $wgMiserMode on a subset of Wikimedia wikis rather than punishing every wiki with $wgMiserMode = true; due to the unusual size of a few wikis. That is, just because the English Wikipedia is very large doesn't mean that the Farsi Wikibooks needs to be constricted and constrained. That's not fair.

If these miser mode-protected features within MediaWiki are truly incapable of working well even on small wikis, then they clearly need to be fixed.

Thanks Sean for updating this report.

(In reply to Sam Reed (reedy) from comment #4)

I guess the step up is to go from doing it once a month like we do currently
to twice a month?

Yes! We also have other bugs about incremental increases for bigger wikis, we just need to avoid forgetting to regularly do it. Who makes some patches? :)

(In reply to MZMcBride from comment #6)

Part of the point of creating https://noc.wikimedia.org/conf/small.dblist
was to be able to disable $wgMiserMode on a subset of Wikimedia wikis

Sure, but there's no need to do them all at once. We could do 100 wikis at a time (a bit boring), or find other interesting groups, e.g. all small wikiquotes and then all small wikibooks and so on: does this work in the current configuration system?

Not a fix for the $wgMiserMode request, but related: https://gerrit.wikimedia.org/r/#/c/168933/

@jcrespo Do you have some thoughts on this topic? I'd like to create a list of ten s3 wikis, one latin, one non latin in each project, and see how they behave with more intensive queries for special pages. Is that acceptable from a dba point of view? Can you help to provide metrics?

Yes, keep me in the loop.

In T48098#3020665, @Dereckson wrote:

@jcrespo Do you have some thoughts on this topic? I'd like to create a list of ten s3 wikis, one latin, one non latin in each project, and see how they behave with more intensive queries for special pages. Is that acceptable from a dba point of view? Can you help to provide metrics?

This sounds good to me. Is there anything I can do to help move this forward?

please note s3 <> small, there are some very large wikis on s3, like cebwiki, which are scheduled to be given more resources, but it happens in batches every some time.

Removing the DBA tag and subscribing myself instead. Once there are specific actions for DBA please re-add us and/or @mention me.

In T48098#3020665, @Dereckson wrote:

@jcrespo Do you have some thoughts on this topic? I'd like to create a list of ten s3 wikis, one latin, one non latin in each project, and see how they behave with more intensive queries for special pages. Is that acceptable from a dba point of view? Can you help to provide metrics?

I could do such test if there's no objection from the Performance-Team, so tagging them.
Among the 550 small wikis defined in small.dblist:

• 514 inside s3
• 1 inside s4 (testcommonswiki)
• 35 inside s5

If possible, I would like to implement like, randomly choose ten small wikis inside s3, two inside s5, maybe another two for non latin sites as @Dereckson mentioned; define them in IS.php then disable wgMiserMode on them inside CS.php. After do so, keep an eye on the performance affect for some weeks, and if no issue found, implement to all small wikis.

I think enabling wgMiserMode in prod whole-sale is probably best not done, at least not without a major audit throughout core and extensions and culture shift in terms of developer knowledge and expectation. There are just too many features and behaviours coupled to this setting that imho strongly have the connotation of "won't ever run in WMF prod" and thus carry much less scrutiny. It's not obvious to me that all of those behaviours are "fine" in production merely because a wiki has fewer pages. It seems likely that those behaviours may very well be abusable by other means.

I note that the original use case here is removing the caching layer from "expensive special pages", and letting them run on-demand instead, e.g. https://alt.wikipedia.org/wiki/Special:Mostlinked. That seems fine to me and is fairly limited in scope and risk. If there are other specific things, I suggest filing tasks for those instead.

The request for special pages appears resolved based on T45668#498526 and https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/47297/. However, looking at the live sites and the associated code in QueryPage.php, it seems that change didn't do anything, or at least not anymore. Special pages that are marked "expensive" are always served from non-expiring cache when wgMiserMode is enabled. The linked config change only modified wgDisableQueryPageUpdate which seeems to not have any effect besides deciding which interface message to show on top. The logic in puppet (source) for updating expensive special pages is the same cluster-wide. Each of these hardcoded ones updates half-monthly, with enwiki disabling even more of them to a monthly rate. I may be missing it, but the fact that for small and medium wikis we clear wgDisableQueryPageUpdate in wmf-config appears to have no effect other than hiding the interface message that says they are updated half-monthly...