[06:39:29] legoktm: wasn't declarative over imperative the entire point of the extension registry system? A hook is more code, more mental complexity, and means you can't really tell looking at extension.json what the extension is doing. A hook just to set an array field seems pretty sad (although that's what I ended up doing after failing to get the config merge logic working) [06:40:34] and extensions set core config settings all the time, isn't that what ExtensionProcessor::$globalSettings is for? [06:46:32] ResourceLoader uses ExtensionProcessor::NOT_ATTRIBS and dedicated merge logic, adding more stuff like that feels like an antipattern. Although I might just not understand what NOT_ATTRIBS is for. [10:34:34] RL needs more logic because it turns strings into absolute file paths, it's not required [10:39:00] The key distinction here is that extensions can't (and imho shouldn't) be using a declarative system to emulate a fragile procedural way to override a global variable. Instead, it's for adding/registering stuff. Those require schema and merge logic to be declared, and then stuff is declarative for those. Most simple ones don't require any functional code in core for this purpose. [10:39:58] tgr|away: eg FileExtensions, GrantPermissions, FilterLogTypes, SpecialPages, RateLimits [10:41:43] Global settings are ones that are exported into the actual global var, afaik that's mostly for back compat, not encouraged for new ones [10:41:50] Core attributes is probably what you want [10:42:43] " not attributes" is similar but those where you want post processing for some reason, most commonly to expand file paths [13:19:37] I see on the rescource loader dashboard in grafana a spike in backend timing for Nov 6 (today) between 8:20 and 9:50 am (UTC I guess), curious if anyone can shed some light on that. no spike the previous 2 days. [17:07:31] apergos: this one, right? https://grafana.wikimedia.org/d/000000066/resourceloader?orgId=1&viewPanel=45 [17:07:59] In investigating a spike like that, I recommend first enabling the "MW deploy" annotations [17:08:10] yes but when I lookes the spike was just one spike, heh [17:08:16] *looked [17:08:48] there was a scap around then but I didn't see anything that helpful in looking at the SAL [17:09:07] unless yo umean that the scap process itself is a cause (!) [17:09:38] Yeah, this is expected after a train deployment. After major deployments, there's a lot of new code so the kinds of requests we have shift from mostly cache-hits to mostly cache-misses for a little while. [17:10:00] ah good to know [17:10:47] Varnish takes care of deduplicating identical requests, but after a major deployment, there'll be hundreds of changed modules * every language * every skin * every wiki. So there's a lot of new backend responses to fill in the caches. It happens pretty quickly, but yeah skews backend timing temporarily toward the kind of requests we normally have only at the p99. [17:11:09] okey dokey, duly noted! [17:11:13] Something that's important to distinguish here is "is the load making us slow" vs "is the load made of the kind of traffic that's slower by itself even in isolation" [17:11:24] In this case, the load isn't affecting us, it's the latter. [17:11:45] This particular metric does have an alert at https://grafana.wikimedia.org/d/000000402/resourceloader-alerts?orgId=1 [17:12:25] and the threshold there is 180s on the moving average of 1h [17:12:29] 180ms* [17:13:07] I'm curious whether there is a way to tell the difference between high load making things slow vs traffic shifting to naturally slower requests. [17:13:26] ah yeah, we have backend request rate one row up on the dashboard [17:13:57] the rate didn't go up at all during the first spike, so that's a fairly strong signal that the traffic is merely shifting from cheap requests to more expensive ones for a little while. [17:14:25] I hope that makes sense, apergos :) [17:14:39] but the question would be why that is, unless as you explain it, there is a deployment [17:14:44] so what are some other possible cases? [17:16:41] or if you remember such a case from the past, that's fine too