[02:58:25] tgr_: I guess the issue isn't k8s itself. It could be made transparent to developers the same way it is transparent for readers and editors. It's that the current workflow doesn't manage the abstractions, so a workflow that used to be simple now forces you to juggle every layer. Which is probably what happens when the people setting it up aren't the ones using it. [04:35:55] bvibber: did you by any chance whip up a simple script to generate the opcache usage stats you cited in the commit message for https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1212717 ? We should compute the same numbers for the Beta Cluster before/after enabling LCStoreStaticArray and I'm lazy :) [04:49:52] There's a magic PHP function that returns the stats, I forget the name offhand but you'll find it in the PHP opcache docs :) [04:50:06] https://www.php.net/manual/en/function.opcache-get-status.php [04:50:28] Yay [04:50:58] but you isolated the contribution of the l10n cache, and also touched every language [04:51:39] I can figure it out, I just thought you might have a magic one-liner stashed up your sleeve. Worth asking :) [11:27:58] bvibber: ori: I suspect this change would reduce per-request memory, since we'd no longer read it from cdb into tmp arrays, and afaik opcache class/file data don't get copied from shares to per-request (unless they change/mutate). I might look at it in a few days if you don't beat me to it :) [11:28:22] If so, that might be a nice secondary win. [11:29:23] esp since preload loads quite a bit upfront current, stored in LocalisationCache. [13:19:50] yeah, harder to measure per-request memory in my isolated benchmark but that should turn up in figures for total memory usage across actual requests being made [13:20:47] if we can then subtract the shared opcache usage we'll have a clearer picture [13:21:01] of how much is going which place :D