[04:20:39] Krinkle: any thoughts on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/668224/9/includes/libs/uuid/GlobalIdGenerator.php#85 ? [16:48:29] bd808: aha cool. [16:49:45] Its a good essay/talk IMO :) Thanks for bringing it back around [17:08:45] AaronSchulz: I suppose we could deprecate and backport, or just support the extra unused arg indefinitely for now and not tell anyone [17:09:15] * AaronSchulz reads https://phabricator.wikimedia.org/T99740 [19:41:55] AaronSchulz: so which way do yuo want to go on UidGenerator? [21:18:46] Krinkle: I don't like wfDeprecated in /libs...maybe a trigger_error? [21:19:52] AaronSchulz: USER_DEPRECATED, yeah, that works. [21:33:45] Krinkle: amended [21:56:43] phedenskog: gilles: some love for Wikipedia re: print & export vs lazy loading https://github.com/whatwg/html/issues/6581 [22:57:40] Krinkle: is https://phabricator.wikimedia.org/T99740 stalled? [22:58:20] AaronSchulz: Yes. need to fix opcache first. [22:59:04] currently awaiting scap turning on the "fpm restarts cycle" feature on each deploy [22:59:11] which is block on some work from SRE [22:59:19] after that we'll turn off opcache.revalidation [22:59:54] and then we can pump all the crap we wantsome carefully selected things into static php and opcache/ram [23:01:29] Krinkle: what about the comments about fpm and kubernetes ? [23:02:21] I'm not aware of any other pending and still relevant blockers [23:03:11] I know there was a misunderstanding earlier on about the size needed (1 vs 2 MW versions), and about deployment times (will be smaller given n more cdb->json+md5>cdb) [23:04:02] I do think we can either ahead of it or after it, take a hard look at the LocalisationCache+MessageCache stack in MW and see if we can rip out one or two layers of indirection. [23:04:31] it seems we currently have json source + cdb files + something memcached + something apc [23:05:21] one thing to consider would be whether it still makes to do fallback backfill at cache time rather than runtime, for example. [23:05:30] and whether ther are other redundancies worth disavling or simplifying [23:06:05] nothing concrete comes to mind right away, just that it currently feels messy and difficult to reason about. perhaps just some refactoring and documenting with no concrete changes in storage/behaviour. [23:06:43] MessageBlobStore might also not be as needed if we can batch fetch at a higher performance. [23:06:55] right now we assume 1ms for message, hence ResourceLoader needs its own cache. [23:07:02] due to memc/sql being involved by default [23:08:40] maybe involving the main stash and a job or something more precached and radical and then something on disk or in apcu. I know you have ideas as well about a less size contrained version of apcu. e.g. "local server stash", which seems interesting to me as well. In prod that could perhaps even share the on-host tier backend. [23:08:57] which mgiht even take the place of apcu entirely in k8s, who knows. [23:10:09]