[14:22:07] MatmaRex: is it removed because of wgExtractsRemoveClasses? https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TextExtracts/+/1048082/4/includes/ExtractFormatter.php [14:22:19] took me a while to find but that's my best guess without verifying locally [14:23:01] yes, because it's a 'div' (and wgExtractsRemoveClasses is not actually classes, but a weird subset of CSS selectors) [18:23:42] Thinking about deprecating two methods in the EventBus extension due to them being unused (afaict), do we have particular suggestions about verifying non-use? I was pondering throwing a log in the method and reviewing later, but there might be options that don't require merging and waiting 1-2 weeks [18:24:04] it wouldn't be removed immediately anyways of course, just marked deprecated [18:26:48] https://codesearch.wmcloud.org/search/ [18:27:00] MatmaRex: for a method named getInstance? fun :P [18:27:30] but i did review all getInstance calls in the release branch manually [18:27:32] heh, yeah, sometimes it's trickier ;) [18:27:47] but i would still give it a try, with some regex searches for the likely variable names [18:28:36] and beyond that, i think that making it emit deprecation warnings is *the* way to verify it is unused. if it turns out to log deprecations in production, it can be easily reverted and investigated. [18:29:20] hmm, i suppose that makes sense and does the same as adding the logging without having to go back a second time to change from logging to deprecated. thanks! [18:29:26] (it's the same as adding custom logging to the method, but better) [18:29:46] (since it automatically logs stack traces, and shows up on dashboards that people review) [21:26:10] MatmaRex: btw, I reviewed the ParserCache dashboard (regarding our risky-patch in TextExtracts extension from last week), and didn't find anything, perhaps slightly surprising. [21:32:49] Krinkle: yeah, i looked at that and the API dahboard too and didn't notice anything significant. maybe it was all already cached. or maybe those API requests are actually nothing compared to normal page view traffic [21:34:05] Krinkle: if you look at this: https://grafana.wikimedia.org/d/000000106/parser-cache?orgId=1&from=now-14d&to=now&viewPanel=32 and select the "unknown" data series only, there is a bit of an increase on the 11th, if you squint a little. the new parser cache writes from that patch would be a part of that [21:35:38] we could use ParserOptions::setRenderReason() in the ApiQueryExtracts code to make it appear as a separate item. i don't think i care that much though :) [21:45:29] MatmaRex: I see. You reckon these are traded in from api_parse? [21:46:09] unknown up from 1K to 3K, api_parse down from ~15K to ~13K kind of? [21:46:38] ah 11th you said [21:47:04] Krinkle: hmm, not sure, i think the action=parse requests previously wouldn't write to the parser cache [21:47:18] They do if you pass a title rather than raw text [21:47:25] except, as you found, when limited to a section [21:48:12] seems impossible to tell if the api_parse counts changed, it's very noisy [21:48:25] yeah, not really worried [21:49:08] what i'm getting from this is that the parser cache backend is quite robust if changes like this barely register [21:49:19] https://grafana.wikimedia.org/d/000000002/mediawiki-action-api-summary?orgId=1&refresh=5m&var-type=api_query&viewPanel=36 [21:49:27] tap the "extracts" legend [21:49:38] cumulative CPU time decreased [21:49:54] bah, that's last 24h [21:50:00] https://grafana.wikimedia.org/d/000000002/mediawiki-action-api-summary?orgId=1&refresh=5m&var-type=api_query&viewPanel=36&from=now-30d&to=now [21:50:34] looking at the 30d view now, i couldn't tell you if that's higher or lower than before [21:51:51] yeah [21:52:11] lastly we have excimer flame graphs which can help pinpoint a shift in where time in spent [21:52:24] i suppose it may be a bit higher, again around 11th. try showing only 'extracts' and 'pageimages' (which is very stable) [21:52:26] https://grafana.wikimedia.org/d/rLMucuf4k/mediawiki-entrypoint-profiling?orgId=1&var-entrypoint=api_query&var-http_method=GET&var-time_grouping_unit=1d&from=now-30d&to=now [21:53:19] this one shows proportionally less time in core_parser overall in api_query, but that's quite a large bucket. [21:53:39] we built this to avoid needing to compare flamegraphs, but in this case comparing two week over week flame graphs might be more useful as you can narrow to TextExtracts [21:53:58] ext_TextExtracts doesn't show high enough to register in that breakdown at all [21:55:16] interesting chart, haven't seen that one before [21:55:44] yeah its nice work by AaronSchulz [21:56:16] https://performance.wikimedia.org/arclamp/svgs/daily/2024-07-15.excimer.api.svgz?s=TextExtract [21:56:27] it seems the api servers are mostly responsible for parsing the help page [21:56:39] >40% [21:57:03] 35% when measuring wall time, https://performance.wikimedia.org/arclamp/svgs/daily/2024-07-15.excimer-wall.api.svgz?s=TextExtract [21:57:16] no TextExtracts there under ApiQuery, too small to register [21:58:56] actually, not 40% but 57% cpu time. I missed a frame. ApiHelp is huge. [21:58:59] That's pretty sad. [22:00:37] https://usercontent.irccloud-cdn.com/file/zt9sXVip/2024-07-15-ApiHelp-58pc-cpu-timepng.png [22:59:48] RoanKattouw: I created a "decisions of things we don't do" section in RL docs you might find interesting. Largely a summary of declined RL tasks over the years, and some resolved tasks about things we removed. https://www.mediawiki.org/wiki/ResourceLoader/Architecture#Strategic_decisions_and_future_considerations [23:00:24] RoanKattouw: one thing that surprised me, is that we actually didn't launch with position "top" and "bottom". We apparenlty hardcoded startup/jquery/mediawiki/wikibits at first and then generalised to a reusable "top" position feature. [23:00:39] Do you recall what that was for? I've linked various things there but trail goes cold. [23:12:40] Nice! It's good to have those things documented [23:13:11] I don't remember what position:top was for. Maybe just for things that modified the DOM so they could do it faster? [23:24:14] yeah, I guess so, but I'm surprised we added it as a new feature after lauching without it. [23:25:00] > This was eventually generalised into a "top" and "bottom" position (T37065). https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/82bf4764ea4f391bf6f9ce732bf91fbd56162cdb%5E%21/ [23:25:01] T37065: Implement 'top' position option for ResourceLoader modules - https://phabricator.wikimedia.org/T37065