[08:49:14] https://developer.chrome.com/devsummit/sessions/future-of-core-web-vitals/ [14:45:39] hey, I've got a few questions/ideas around User object caching - not sure if this is the best place for them, but I'll ask them here based on 'git blame' results: [14:45:39] currently, User cache entries are wiki-local, since user tables are wiki-local in a default setup & contain other wiki-local info like group memberships. [14:45:39] however, we're using a shared user table configured via $wgSharedDB + $wgSharedTables. [14:45:39] This creates a situation where if the user record is updated from one wiki, changing the user_touched TS, subsequent updates to the same user from other wikis can fail on the user_touched CAS check, since cache entries for other wikis aren't cleared and so will continue to hold a stale timestamp. [14:45:39] my question is: would it make sense to add a mechanism for users caching if a shared user table is involved to avoid that? we opted to add a global checkKey to the user cache so that entries for a given user can be easily invalidated via touchCheckKeys() - https://github.com/Wikia/mediawiki/pull/16/files [14:51:16] another alternative could be to introduce a hook in loadFromCache() so that an alternative cache loading mechanism can be provided, which would allow for less complexity in core at the cost of adding a hook invocation [15:28:06] mszabo: hmm intuitively I'd expect CAS not to use cache. That seems like it's own bug [15:28:39] mszabo: there is a method for clearing cache afaik, used by CentralAuth for example [15:30:32] mszabo: I might look at the code later, but a checkKey based on a global Id provided by authMgr should make it all work nicely both for shared table and CA [15:30:34] yeah, but that method clears the cache for a single wiki [15:30:56] as for the CAS check - in case of failure, it does invalidate the user object, but then throws an mwexception: https://github.com/wikimedia/mediawiki/blob/master/includes/user/User.php#L3405 [15:32:15] I mean user objects that read from latest as one would before a CAS update, shouldn't even use the cache anyway [15:33:08] true, there's getInstanceForUpdate() [15:33:08] once we checkKey on our standard global Id concept we can also automatically touch that from core. Would over purge for CA but seems harmless [15:33:33] There's all sorts of ways in which not doing that would naturally throw a failure CAS [15:33:53] If you ran into some, worth reporting [15:34:02] I'll be back in a bit [15:34:05] yup, looks like there are a few pages that might not be using it, so I'll probably submit some patches there [15:36:35] heh, fixed in https://phabricator.wikimedia.org/T226337... guess we just need to upgrade again :P [15:56:51] https://estimator.dev/#en.wikipedia.org [16:15:46] gilles: looks pretty good as is.... [17:14:21] Krinkle: https://calendar.perfplanet.com/2020/profiling-php-in-production-at-scale/ [17:22:54] :) [17:34:41] phedenskog: how far along is your post? [17:35:42] Mine was three days in pending, about the same as last year so that gives you a sense of the backlog [17:35:56] I submitted one day later than last year [19:48:09] gilles: looks like the last few asreports (not yet in HTML form) have lost the labels for USA, they're all in some kind of all-caps abbreviated form when I try it out locally [20:01:40] Krinkle: can https://gerrit.wikimedia.org/r/c/mediawiki/core/+/589465/10 be merged? [20:03:32] yup, loking at PS10..14 now [20:03:34] landing [20:03:43] AaronSchulz: shall we do the graphite stuff now? [20:28:04] Krinkle: ok [20:31:14] * Krinkle updated [[wikitech:Graphite]] [20:31:16] so it [20:31:22] primary is 1004 and 2003 nowadays [20:32:05] do you want to drive, and/or do you need my input at all? I lost track, sorry if you said that already [20:33:08] I would normally do a dry-run in a small shell script that would list the files instead of deleting them. and then scp it down/up t the other host and run it there as well dry and non-dry [20:33:31] e.g. using find and rm, over /var/lib/carbon/whisper [20:34:54] Krinkle: I don't recall doing this before [20:36:13] okay, np [20:36:28] this is a fairly tricky one at that since there isn't a clean prefix for what we want to remove, right? [20:36:43] let's PM [23:51:22] gilles: did you see this? https://www.ctrl.blog/entry/webp-avif-comparison.html [23:51:33] (mentions you, found it just now)