[06:02:56] * Krinkle is looking at SVN r2261 "Angela's disclaimer in top links" - https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/d2dbe2607bbd0a4cfe410567e28b82b53c6206d8%5E%21/includes/Skin.php [06:36:27] before we were in a relationship [06:48:14] :) [07:13:06] I'm reviewing the tasks but I'm probably going to recommend x2 for centralauth sessions [07:20:24] TimStarling: ack. another option that came to mind for sessionstorage long-term more generally is perhaps a slightly redundant memcached setup, e.g. a small pool of memcached in both dcs including a gutter host, and then the mcrouter write route for it would be set async to both DCs and both gutters, as well as for mcrouter to use its buffer/replay logic to recover any temporarily down hosts. This would mean we generally keep sessions [07:20:24] even if one host goes down or needs maintenance. But it also means that when we do lose stuff, people get logged out unless the remember-me autologin feature is set which would allow session to transparently be re-created without any kind of reload or notification noticable client-side (apart from possibly a badtoken error that bots and JS clients auto-retry these days). [07:21:01] it's a more extreme approach to sessions perhaps, might be too fragile, but would also encourage less things like the Collection extension which probbly shouldn't be putting its drafts in the session in the first place. [07:21:33] I'm fine with mainstash though if it doesn't pressure us to reduce session lengths. [07:21:57] I don't have a quote of datasize handy, but anyway centralauth session data as start would certainly be fine indeed. [07:23:21] I'm also wondering to what extend remember-me is considered rare or default, and whether that is actually working as well and as transparently as it could/should. But none of that is blocking right now. [10:09:03] Krinkle: hey, for when you have time, I have some... interesting experiences with the fix for T222539 that made the MessageBlobStore check key global [10:09:03] T222539: Scap deployments are not purging MessageBlobStore (was: Stale localized messages) - https://phabricator.wikimedia.org/T222539 [10:09:43] crucially, since MessageBlobStore::clear() is called from DatabaseUpdater::purgeCaches(), it means that each completed update.php run drops the MessageBlobStore cache for *all* wikis, not just the wiki that got updated [10:11:13] this ended up making MessageBlobStore the single most trafficked key class for our MC (and causing some 3%+ of time to be spent in MessageBlobStore::recache) [10:11:52] I wonder if it may be useful to have both a global and a wiki-local check key for MessageBlobStore, the former to be invalidated by rebuildLocalisationCache.php / purgeMessageBlobStore.php and the latter to be invalidated by update.php [10:12:34] aside from people running schema changes using update.php in a loop across multiple wikis fairly often, we also run update.php as a final step in the self-service wiki creation flow [10:12:52] so the global MessageBlobStore cache ends up being invalidated every minute or so [11:02:04] Krinkle: reading my own comments was very enlightening [11:02:26] now I know what you mean when you say that I probably want kask instead of mysql [15:36:57] mszabo: ack, that's an interesting issue indeed. update.php is I imagine for many cases the one script they run after upgrading the source code and thus i18n files, so yeah a local purge is def needed, but not a global one indeed. [15:37:41] update.php can actually run rebuildLocalisationCache as a child [15:38:00] but it runs it as actual script child, when manualRecache=true, so that should all work out still. [15:38:37] but... depending on whether Fandom indeed use manualRecache=true, that would make it still do the same issue. [15:39:11] Yeah :( [15:40:23] mszabo: Id accept a patch to skip-l10n-rebuild or some such to update.php [15:40:47] yeah, that's probably the simplest fix :) [15:40:47] possibly covering both of those two branches [15:40:57] https://gerrit.wikimedia.org/g/mediawiki/core/+/dff8a1571e2d404df9cafcd3c8667d7b02734ecd/includes/installer/DatabaseUpdater.php#1109 [15:41:21] well... a change in l10n is not the onluy reason to clear [15:41:27] its also a reason to clear if the module contents change [15:41:28] * Krinkle checks [15:42:11] ok, we already cache naturally by including hash of contents in the key so no worries [15:42:24] yeha it's only for regular l10n rebuilds [15:42:38] the messageblobstore clear being for the default case (manualRecache=false) and then manualRecache=true for that. [15:42:46] under manualRecache=true it's technically going to do it twice [15:43:08] hope that helps :) [15:43:46] Sounds good, thanks