No in-process cache for CentralAuthUser
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Tgr
	Feb 17 2016, 9:04 PM

Description

If the same CentralAuthUser object is loaded multiple times in the same process, each load triggers a WAN cache read. Fixing that should be trivial and low-risk - just make sure the in-process cache is memory-limited (e.g. HashBagOStuff with an entry count limit) and is invalidated any time the WAN cache is.

Details

Subject	Repo	Branch	Lines +/-
Cache CentralAuthUsers more aggressively	mediawiki/extensions/CentralAuth	wmf/1.27.0-wmf.13	+59 -25
Cache CentralAuthUsers more aggressively	mediawiki/extensions/CentralAuth	master	+59 -25
Cache CentralAuthUsers more aggressively	mediawiki/extensions/CentralAuth	wmf/1.27.0-wmf.14	+59 -25

Customize query in gerrit

Related Objects

Mentioned In: T127772: MWSession redis key retrieved 8-9 times per page request
T127396: Logins with CentralAuth fail when password re-hashed
T126700: Severe save latency regression

Event Timeline

Tgr created this task.Feb 17 2016, 9:04 PM

Tgr raised the priority of this task from to Needs Triage.

Tgr updated the task description. (Show Details)

Tgr added a project: MediaWiki-extensions-CentralAuth.

Tgr subscribed.

Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptFeb 17 2016, 9:04 PM

Filed mainly because SessionManager used to initialize the session multiple times for a single request, due to backwards-compatibility with PHP's internal session handling and limitations on what can be cached in-process without messing up HHVM garbage collection; I cannot reproduce that behavior anymore though. @Anomie, did something change there?

Tgr mentioned this in T126700: Severe save latency regression.Feb 17 2016, 9:13 PM

While SessionManager does create a Session object multiple times, it will generally only be determining the session from the request cookies and headers once. The rest of the times it should just be loading the session from the SessionID saved in the WebRequest after that first determination.

The PHP backwards-compatibility stuff (MediaWiki\Session\PHPSessionHandler) never actually determines the session from the request cookies and headers, since it always deals with a passed-in session ID.

However, CentralAuthSessionProvider::refreshSessionInfo() probably will be called for every Session object created, even if it is created from an ID, and that does create a new CentralAuthUser for each call.

Unfortunately we can't use a CachedBagOStuff here, since CentralAuthUser stores its stuff in a WANObjectCache rather than a BagOStuff of any sort.

Instead of putting something transparent before the WANObjectCache I would rather cache the central user objects themselves and add another layer of cache lookup.

Tgr mentioned this in T127396: Logins with CentralAuth fail when password re-hashed.Feb 19 2016, 7:04 PM

Change 271803 had a related patch set uploaded (by Anomie):
Cache CentralAuthUsers more aggressively

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

gerritbot added a project: Patch-For-Review.Feb 19 2016, 7:20 PM

ori awarded a token.Feb 22 2016, 11:09 AM

Change 271803 merged by jenkins-bot:
Cache CentralAuthUsers more aggressively

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

ReleaseTaggerBot added a project: MW-1.27-release (WMF-deploy-2016-03-01_(1.27.0-wmf.15)).Feb 22 2016, 10:00 PM

bd808 mentioned this in T127772: MWSession redis key retrieved 8-9 times per page request.Feb 23 2016, 12:09 AM

Change 272642 had a related patch set uploaded (by Paladox):
Cache CentralAuthUsers more aggressively

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

Change 272642 merged by jenkins-bot:
Cache CentralAuthUsers more aggressively