[22:18:56] https://usercontent.irccloud-cdn.com/file/v2bMo6JY/res.svg [22:19:12] cases of Message::parse showing up in arclamp logs [22:19:38] these two fixes came out of it: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1277766 [23:45:13] Amir1: you're thinking of caching outside process or in-process? i.e. calls across requests or repeat calls? [23:46:09] depends on the case I think. One thing that is clear is edit warnings, I assume we can cache the BLP warning [23:46:20] cache it on memcached I mean [23:46:52] For stuff that's heavy in complexity, such as sitenotices, recentchanges legend, history header, action=info footer. Some of these don't vary by page and could be cached in memcached in a way that's probably worthwhile (because we'd save non-trivial parsing that includes db queries) with a brief TTL. We have several of those cached already. Incl via RL modules where we force content language and force no page / no user variance [23:46:52] naturally. [23:47:36] currently, 60% of Message::parse is the edit intro. Some vary by page but I guess mostly not [23:47:58] I'm not sure about generalising that too much since it's hard to tell when it's worth it, but these are very short in use cases. There isn't a long tail afaik, so wancache->getWithSet is pretty much as generalised as it needs to get, and takes very little boilerplate, and avoids "surprise" effects. [23:48:50] Aye, yeah, those are tricky. It's not particularly sensitive latency wise afaik, but with scrapers hitting action=edit it occupies appservers. So less about user benefit in that case and more about throughput I suppose. [23:49:22] I believe majority of traffic is on wikis where editintro is a single dynamic template that does "everything" and varies by title definitely. [23:50:24] https://en.wikipedia.org/wiki/MediaWiki:Editnotice-0 > https://en.wikipedia.org/wiki/Template:Editnotice > https://en.wikipedia.org/wiki/Template:Editnotice_load/core [23:50:36] from there, handes a ton of cases. [23:50:56] spent a ton of time on this back in the editing team because VE loads it in the critical path [23:51:48] It used be an argument like notice=BLP_intro [23:52:01] set via js I guess, but that was long time ago [23:52:16] One of the things I did was get rid of the ancient hacks that relied on display:none or empty divs, so that these messages/templates must parse to empty string if there is nothing to display (so that VE can decide very effiently whether to open the popover and say "N notice(s)" whereas wikitext edit form didn't need to know, it just printed it there and looked empty or not. [23:52:31] Ah, that's an optimisation for a specific case, yeah. For BLP it is category based. [23:52:50] There is/wasn't a way to know in wikitext if a page is in a category, so JS added that based on pageview wgCategories, as an extra notice on top of everything else. [23:53:07] That's a fairly small part of the puzzle. Majority is dynamic through that template. [23:53:13] yeah [23:53:31] There is also 10% on formatting change tags in history [23:53:37] could be optimised via Lua, I think some wikis do that. batching, preloading, making those things fast/cached intenrally where possible. [23:56:34] one of the things we also did back then, if I recall correctly (or maybe it was that way already) is make namespaces a native thing. [23:56:46] eg. https://en.wikipedia.org/wiki/MediaWiki:Editnotice-8 [23:57:00] so that way most of the non-mainnamespace edge cases don't need to be loaded [23:57:04] https://usercontent.irccloud-cdn.com/file/ES4kfe75/grafik.png [23:57:21] > $tagInfo['description'] = Sanitizer::stripAllTags( $localizer->msg( $descriptionMsg )->parse() ); [23:57:22] esp when it was all wikitext without lua, that saved a fair bit as it meant that on most articles/ most wikis, it is simple. [23:58:10] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1130301 [23:58:11] ref T344352 [23:58:12] T344352: Rendering tags dropdown is slow on Special:Contributions (via ChangeTags::getChangeTagList) - https://phabricator.wikimedia.org/T344352 [23:58:20] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/948557 [23:58:25] > ContribsPager: Put tag parsing behind an in-process cache [23:59:10] there's two unfinished patches there [23:59:39] I see yours is action=history but probably similar issue [23:59:51] although again, amplified by scrapers traffic