[03:09:28] hi. I have a couple patches pending that combine ResourceLoader modules that are always used together - can I request reviews here? [03:10:17] In general maintenance and perfomrance improvments should be reviewed by their owners. If it is not a change relating to the framework itself or a core module provided by the framework (see https://phabricator.wikimedia.org/tag/resourceloader/ ) then we generally would not maintain that. [03:10:32] oh, okay [03:10:34] thanks [03:10:46] https://phabricator.wikimedia.org/project/profile/274/ * [03:10:50] youre welcome :) [03:10:58] such changes also need proper testing :) [03:11:04] ideally by someone familiar with the feature(s) [21:43:10] Krinkle: out of curiosity - is there a graph that would show me average/p9x request latency for simple page views on appserver level? [21:46:28] Pchelolo: no, not that I know of. we have appserver backend timing by host and by cluster (so we have parsoid vs jobrunner vs api_appserver vs "appserver" appserver (index.php & load.php more or less)). We also have a separate collector for all load.php traffic and I think also one explicitly for api.php traffic broken down by indiviudal action APIs. [21:46:41] we also have edits separated out in their own metrics [21:48:24] hm, ok. We've recently realized we are reading from ParserCache multiple times over the course of a request, so we wrapped it with a small scale CachedBagOStuff.. wanted to see if it shows anywhere. [21:48:49] and in general we finished with ParserCache for now, wanted to see if there's any difference [21:49:07] Pchelolo: I meant to ask why that was done, as I'm not aware of that hapening under normal conditions. [21:49:50] page views make up the majority of app server traffic,so those merics should be good to use [21:50:06] we also have flame graphs for that code path specifically which can show a proportional shift week over week [21:50:21] eg. less time spent in page views and/or that part of page view functions [21:50:29] oh can you give me a link for what to dig into? [21:50:37] that's how I usually find/verify individual low level changes [21:50:45] https://performance.wikimedia.org/php-profiling/ [21:50:51] https://performance.wikimedia.org/arclamp/svgs/daily/2020-12-16.excimer.index.svgz [21:50:51] cool, thank you. [21:51:07] ctrl-f Article::view [21:51:42] (has to be actually ctrl-f, not native equivalent) [21:54:27] as for cache bag - we introduced a general-purpose service for getting parser output, wrapping parser cache and pool counter and all that [21:55:08] and looking at metrics realized that sometimes there's more parser cache accesses then calls to this new service from article::view [21:55:48] and in general, any extensions that uses WikiPage::getParserOutput just hits parser cache [22:04:19] which metrics? [22:33:30] dpifke: that's awesome, nice work (speedscore access to arclamp logs)