[00:09:59] AaronSchulz wrote most of the original code in 2007, with a contract from WMDE (this predated his employment by Wikimedia) [00:10:21] I was reminiscing about this and reviewing emails from the time because Moriel mentioned it [00:10:47] I was assigned to review it [00:11:23] and once you touch a thing, you own it forever, right? [00:32:43] That's how it tends to work around here [00:32:58] "You touched that thing once, a decade ago... You must know what's going on, right?" [06:37:57] Hi! What's the multi-DC-appropriate way of warming a WAN cache? If I just push a job to call WANObjectCache::set, that will only run in the primary DC, I assume. [07:43:25] yeah just primary, there's no warming feature [07:43:30] you can use mainstash though [09:29:16] tgr_: warming a cache is a pattern we phased out since 2015 in favour of getWithSet. It depends on the specifics, but so far when we've seen this pattern, the resolution has afaik always been not to warm it going forward. [09:29:23] Some relevant thoughts at https://wikitech.wikimedia.org/wiki/Memcached_for_MediaWiki#WANObjectCache [09:31:25] Specifically about using replicas only, and not expecting values to last. There are other affordances for edge cases. Depends on the requirements I suppose :) [09:32:43] I've also rewritten this a while back to reflect current practices around caching, https://www.mediawiki.org/wiki/Manual:Object_cache [09:40:30] The use case is a slow query (seconds) that depends on the user, so without warming everyone would see a slow page load first, and it's a prominent UX shown shortly after registration (the list of suggested editing tasks on the new users' homepage). [09:42:21] The main stash would work, it's just a bit of a pain to switch between the very different WANCache and BagOStuff interfaces. [09:44:26] I remember them as having the same three methods (getWithSet, makeKey, set) with the same basic signature / param order. Perhaps it ended up different by accident though. [09:46:19] I assume you have a workflow then where at some point you anticipate the homepage is visited and are trying to start the preload from there in a job. But if the user visits it a different way or after it expires, it'll be slow again. [09:48:23] I vaguely recall that the mentor/homepage related data was precomputed via a maintenance script. Could this be computed as part of it? [09:49:34] In any event, yes, some estimate of size, usage and retention may be worth providing to DBAs, but MainStash could be a quick no-schema way to persist days for a reliable period of time. [09:50:04] I.e. not subject to LRU pressure in memcache. [14:35:45] Yeah, both have a getWithSetCallback method but the capabilities are quite different. E.g. WANObjectCache has in-process caching built-in as an option, plain ObjectCache uses a decorator. WAN supports key sets, plain doesn't. WAN can be used to revalidate (run the callback even if there is a cached value), plain cannot. So switching from one cache type to the other can mean having to rework the calling code quite a bit. [14:38:26] Using a maintenance script instead of a job would probably be doable, but I don't think it changes anything - we still wouldn't be able to target both data centers, right? [14:44:50] tgr_: ack, there's some differences. In my experience though 99% is $cache->getWithSet( $cache->makeKey(), ttl, callable ) which is interchangable between the two. [14:46:16] a maintenance script can write to MainStash for sure, though 'warming a cache' is likely to lead to surprises at one point to another as the maint script would presumably be exhaustive and not based on activity or demand. For such data a dedicated table might be better suited. [14:46:29] True. We use the revalidation feature so it would be a little more complex in this case. [14:46:40] got a link? [14:47:54] https://github.com/wikimedia/mediawiki-extensions-GrowthExperiments/blob/b521a846d519da1704e5cd241ab9e2d59856551c/includes/NewcomerTasks/TaskSuggester/CacheDecorator.php#L83 [14:48:44] or more to the point, https://github.com/wikimedia/mediawiki-extensions-GrowthExperiments/blob/b521a846d519da1704e5cd241ab9e2d59856551c/includes/NewcomerTasks/TaskSuggester/CacheDecorator.php#L185-L189 [14:51:25] I guess it's not actually very complex, we just need to replace getWithSetCallback with a manual get + validate + set. For the WAN cache that would be a little scary because get/set and getWithSetCallback seem to have diverged quite a bit. For BagOStuff getWithSetCallback is trivial though. [21:55:54] Jdlrobson: I imagine that modules with maintainer names but without a steward are in the "not really maintained" bin. The names are just the best points of contact for something urgent.