[02:58:47] Progress report on Backend Pageview Timing, looking back 1.5y: https://phabricator.wikimedia.org/T302623#11730913 [03:09:37] That hurts. Is it all parser cache churn? [03:11:52] I don't understand https://phabricator.wikimedia.org/T394059 (Post-cache output transforms are expensive on large pages). It diagnoses where time is being spent but doesn't explain the change. [04:06:17] there are various unexplained bumps along the way. The big one after Nov 2025 could be all TTL/ParserCache churn related. Hard to be sure, but there's definitely more baked into the current baseline than there was in Jan last year [04:08:08] My understanding is that the Parsoid team moved something that used to be part of the parser run, to be a separate post-processing layer. Thus allowed more cache re-use so fewer "complete" cache misses, including shared parser cache between desktop and mobile (possibly other use cases that have variants, not sure). For parsoid especially where some of those things weren't supported otherwise as its parser has fewer variants, and some [04:08:08] features of the legacy parser only work via the new post-proesing layer in Parsoid, so we went from legacy supporting a thing built-in and Parsoid not supporting it, to legacy parser not using that feature, parsoid still not supporting it, and then post-procesing doing it for both. [04:08:28] That post-processing was initially added without caching, on the guess (I suspect) that it would be fast enough. [04:10:01] That turned out not to be the case, so eventually (I don't recall when, but I think between Feb-Oct 2025 somewhere) a separate parser cache key layer was added for thist post-processing pipeline [04:10:11] The post-procesing pipeline, in name, will probably be a new concept to you. [04:10:42] But you might know its predecessor, ParserOutput->getText which returned the ParserCache html, and inserted edit section links via the Skin class. [04:10:47] that never need caching. [04:11:07] via placeholders in the cache value.. that goes back more than a decade [04:11:53] That function was turned into a big class hierachy, including various features that Parsoid otherwise lacked (see OutputTransformPipeline, and OutputTransformStage). [04:12:10] This task doesn't seem to have commits attached to it that add caching for it. [04:13:03] but it did happen at some point. Looks like that task maybe focussed on reducing the number of repeat Remex parse/serialize pairs between html-string transforms and dom-based transforms. [04:13:09] mainly( [04:13:10] mainly* [04:14:06] There might be more room for optimisation in that pipeline still, but given it now has parser cache caching, it should be more or less the same as before, at least for parser cache hits. [04:14:45] the other regressions might be unrelated to parsing and parser caching. dont' know :) [04:15:00] we also seem to be in the habit of adding db queries on page views for various reasons. [04:15:41] there's a few subtasks on T302623 that focus on that, such as T347123 [04:15:42] T302623: FY2022-2023: Improve Backend Pageview Timing - https://phabricator.wikimedia.org/T302623 [04:15:42] T347123: Reduce database queries on parsercached logged-out page views (Sep 2023) - https://phabricator.wikimedia.org/T347123 [04:15:52] * Krinkle AFK [21:06:33] Anyone know why centralid stuff is annoying? :P [21:06:54] Locally... getTestSysop() gets me a user with a central id... [21:07:09] getTestUser() does not [21:07:19] But neither work in CI [21:07:24] under OATHAuth anyway [21:09:21] Is it because it loads CA in the CI context and I need to override CentralIdLookupProvider... [21:13:17] hrm, I thought we fixed that bug? [21:14:10] which one? :) [21:14:30] https://gerrit.wikimedia.org/r/c/mediawiki/extensions/OATHAuth/+/1256517/6..7/tests/phpunit/integration/Maintenance/DisableOATHAuthForUserTest.php fixes it in our CI