Page MenuHomePhabricator

Startup manifest for logged-in users are minified and cause rapid objectcache growth
Closed, DeclinedPublic

Description

Some of the timestamps in the startup module are user-specific, which means a lot of different versions of the startup module are served. These all get run through the minifier, which puts them in the minifier cache. This caches the result by MD5 hash, and the cache entry never expires. This is wasteful but OK in a system like memcached that does LRU eviction, but it's much less OK in a system without evictions, such as the objectcache table.

According to the report at https://www.mediawiki.org/wiki/Talk:ResourceLoader#Cache_consumption_20440 this leads to something like 30 MB/day of cache growth, which is bad. We should redesign the minifier cache to behave more gracefully.

See also:

Details

Reference
bz42094

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:04 AM
bzimport set Reference to bz42094.
bzimport added a subscriber: Unknown Object (MLST).
Krinkle renamed this task from Minifier cache + user-specific module timestamps = rapid objectcache growth to Startup manifest for logged-in users are minified and cause rapid objectcache growth.Apr 10 2015, 7:59 PM
Krinkle updated the task description. (Show Details)
Krinkle set Security to None.
Krinkle updated the task description. (Show Details)
Krinkle removed a subscriber: Unknown Object (MLST).
Krinkle claimed this task.

I've re-evaluated this and my assumption was incorrect. The startup module does not take user sessions into account.

In Wikimedia deployment, Varnish ensures cookies are stripped anyway (T101892). But even for setups without this, I've verified ResourceLoader does not consider the user from the session when computing e.g. the version hash of the "user" module.

It only does this when there is an explicit user query parameter in the request, which we only do when requesting the user module for logged-in page views. Never to the startup module.

The cache object growth observed was genuine, but caused primarily by T84960, T94810 and related tasks.