Cite extension is causing ParserCache split by interface language
Closed, ResolvedPublic2 Estimated Story Points
Actions

Assigned To

Authored By

	awight
	Dec 11 2019, 9:30 AM

Description

The extension needs ParserOptions#getUserLangObj to render errors, but a side-effect of this function is that the ParserOutput will be specific to an interface language rather than content language. A patch (342e231a224) on both wmf.8 and wmf.10 makes this issue much worse by splitting cache as soon as the Cite extension is loaded (most pages), rather than only when errors are present (very small percent of pages).

We have a fix to backport in SWAT today: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Cite/+/555075/

To my untrained eye, it looks like we've already had a large impact on ParserCache hit rate, maybe -10% from the usual: https://grafana.wikimedia.org/d/000000106/parser-cache?orgId=1&from=1575451836150&to=1576056636151&var-contentModel=wikitext

Update: The drop in hit rate, if any, was more like 2-3%.

Details

	Subject	Repo	Branch	Lines +/-
	Lazily fetch user interface language to prevent cache split (take 2)	mediawiki/extensions/Cite	wmf/1.35.0-wmf.8	+19 -6

Customize query in gerrit

Related Objects

Mentioned In: T330677: Ensure ParserCacheMetadata isn't corrupted by 'useParsoid' option
T239988: Review feature: Reference errors are split by user interface language
rECIT2463f3c03158: Lazily fetch user interface language to prevent cache split (take 2)
Mentioned Here: T239988: Review feature: Reference errors are split by user interface language
rECIT342e231a2242: Extract all error reporting to a CiteErrorReporter

Event Timeline

awight created this task.Dec 11 2019, 9:30 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 11 2019, 9:30 AM

awight added projects: Performance Issue, MediaWiki-libs-BagOStuff.Dec 11 2019, 9:31 AM

WMDE-Fisch moved this task from Sprint Backlog to Review on the WMDE-QWERTY-Sprint-2019-12-11 board.Dec 11 2019, 12:12 PM

WMDE-Fisch set the point value for this task to 2.

Update: the patch for wmf.8 turned out to be bad, so we're prioritizing the wmf.10 fix for today. Maybe we'll have an updated wmf.8 hotfix ready for tomorrow, but the rewards are diminishing.

On second thought, we're definitely going to try the wmf.8 hotfix again tomorrow. It seems worthwhile, because any delay in deploying wmf.10 would leave us splitting the cache until next Monday at the earliest.

Change 556372 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/Cite@wmf/1.35.0-wmf.8] Lazily fetch user interface language to prevent cache split (take 2)

https://gerrit.wikimedia.org/r/556372

gerritbot added a project: Patch-For-Review.Dec 11 2019, 3:13 PM

Change 556372 merged by jenkins-bot:
[mediawiki/extensions/Cite@wmf/1.35.0-wmf.8] Lazily fetch user interface language to prevent cache split (take 2)

https://gerrit.wikimedia.org/r/556372

awight mentioned this in rECIT2463f3c03158: Lazily fetch user interface language to prevent cache split (take 2).Dec 11 2019, 7:15 PM

Mentioned in SAL (#wikimedia-operations) [2019-12-11T19:33:15Z] <awight> Overriding scap canaries for T240426

Mentioned in SAL (#wikimedia-operations) [2019-12-11T19:34:04Z] <awight@deploy1001> Synchronized php-1.35.0-wmf.8/extensions/Cite: SWAT: [[gerrit:556372|Lazily fetch user interface language to prevent cache split (take 2) (T240426, T239988)]] (duration: 00m 40s)