[00:03:39] it would work, but it limits the scope and lifetime of the cache to the kubernetes pod [00:05:50] aye, I thought you were thinking of a variation of apuc_fetch that's more optimal. Short of storing a file or using memcached, I'm not sure how we can exceed the lifetime of a pod? [00:09:01] use memcached [00:21:11] what is the lifetime of a pod? a single request? [00:22:42] given no auto scaling, presumably the same as the life of a php-fpm process today, i.e. until the next scap deploy. [00:23:01] but I'm not so sure now given Tim's thinking. [00:24:08] (noting that since ~1y ago we disable opcache revalidations and restart php-fpm after each deploy with 1s depooled state to drain requests over a rolling restart; a spiritual successor to HHVM RepoAuth kind of... sort of..) [01:05:38] zero-copy, in-place deserialization is what capn proto and flatbuffers do, I think it could work well [01:29:29] Krinkle: not that APCu has much in the way of GC either :) [01:31:10] I'll eventually want to briefly profile MW in production after rebuilding PHP and its family with debug symbols to see how much of the impact is deserialization vs memcpy [01:31:56] with a test deployment and synthetic requests it seemed mostly the former, but would need real data to draw consequences from [01:37:49] mszabo: does Fandom use igbinary? [01:38:26] for APCu, yeah - an 768M SHM was unusable without it [01:38:36] ref T225074, T318306 [01:38:37] T318306: Evaluate igbinary for php-memcached at WMF - https://phabricator.wikimedia.org/T318306 [01:38:37] T225074: Evaluate using igbinary for MW php-apcu at WMF - https://phabricator.wikimedia.org/T225074 [17:53:29] immutable_cache looks great, imo [18:24:45] it is, if you're sure you won't exceed the limits :) [20:34:34] ultimately maybe one endgame for extensionregistry could be to do what we do for i18n JSONs already - compile the data into PHP files, load those in production [20:34:40] from there it's opcache's problem :) [20:58:55] yeah, we could do something akin to GitInfo or Interwiki map. If a certain php file exists / is given / is assigned; use it, and otherwise apcu/getWithSet as normal. [20:59:46] We could even consolidate these things, together with i18n, into a single maintenane script for immutable installs, ideally without needing to configure anything. [21:00:50] mszabo: we don't yet use php array l10n at WMF btw, it's queued up after mw-k8s and php8.1 are done (for mw-k8s, "done" means sufficiently few mw appservers left that reimaging for php8 is a relatively small task, e.g. just mwmaint/jobrunner) [21:01:16] we're still dancing with json->cdb->md5->cdb->json through scap on every deploy. [21:01:49] that should be cdb->json->md5->json->cdb * [21:05:30] but yeah for things that aren't too terrible to compute on demand, immutable_cache could let us automate a lot of things without configuration. E.g. one feature flag to say use immutable_cache if it's availalbe for tons of stuff without any verification or recompute. If reading data from there is comparable to opcache, it might be preferable to keep doing it lazily so as to not need to deal with writing/executing php files as much. From [21:05:30] there it's a trade-off between running a script during image building vs a warmup request before pooling a pod. Script seems appealing and more efficient by not re-doing on every server. On the other hand, warmup would mean more code re-use and possibly a good idea regardless for other things that can be warmed up as well. E.g. message cache, and a bunch of other things. [21:05:52] We're definitely moving from ~100 web servers per DC to a notably higher number of pods as I understand it so that emphasises per-server misses much more. [21:06:11] (web servers, discounting api/job)