[00:17:39] AaronSchulz: so, landing as-is or more tests before tomorrow? https://gerrit.wikimedia.org/r/c/mediawiki/core/+/640868/ [00:57:48] Krinkle: I'll amend [01:29:28] Krinkle: done [08:34:38] firefox 83 is becoming stable today and it comes with major SpiderMonkey perf improvements: https://hacks.mozilla.org/2020/11/warp-improved-js-performance-in-firefox-83/ [08:34:49] eg. they claim 20% faster load time of Google Docs as an example [08:50:25] I will roll it out later today. [17:14:00] Someone around who can +2 https://gerrit.wikimedia.org/r/c/analytics/statsv/+/639223? [17:18:20] dpifke: should ideally be someone from analytics nowdays, although it does still autodeploy/run from webperf service. would be good to have maybe milimetric or ottomata review it just so we keep those paths well-walked. [17:18:53] OK. I didn't realize it hadn't merged, so it's broken right now because the puppet change went live. [17:19:37] looks like CI isn't setup? [17:19:49] and we no longer have +2 to the repo [17:19:51] so I can't anyway [17:19:56] so yeah ping those folks :) [17:20:14] Will do. [17:57:01] D'oh, looks like I also broke navtiming. Fix here: https://gerrit.wikimedia.org/r/c/performance/navtiming/+/641464 [18:49:53] Is there any easy way to turn off the stuff that is done in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/538362 ? [18:50:28] I'm still trying to debug on my system and see if I can figure out exactly why its broken (its even broken in one situation with wgDisableOutputCompression = true ...) [18:51:40] It looks like a bug in the path for DEFER_SET_LENGTH_AND_FLUSH somewhere [18:52:25] addshore: depends on what you mean by "the stuff" [18:52:50] the behaviour of job execution is configurable, effectively wgJobRunRate 0 or >0. [18:53:02] the behavour of post-send I'm not sure is configurable, but it is easy to patch [18:53:26] from the MediaWIki.php __construct [18:54:09] hm.. you mean you have neither shutdown nor postsend support on your setup? [18:54:13] aye that's tricky then [18:55:31] nope, not currently [18:56:19] The annoying thing is that I can't even see what is wrong, i'm in the situation where tihngs now load in my browser after setting wgDisableOutputCompression = true, however some other service that are hard to debug (an uptime check) gets a 200, but seemingly with some missing content [18:56:40] and I havn't been able to actually debug that uptime check, so instead needing to look at MW instead [18:57:40] One of the main things I notice is the addition of the content-length header, that remains even in the case of wgDisableOutputCompression = true [18:58:55] I mean, I could try and post send / end of request support https://github.com/wikimedia/mediawiki/commit/4f11b614544be8cb6198fbbef36e90206ed311bf#diff-6a25b7d123e94e4ae53bd62ecb2ebac4d94d85090177605742bcfda53d3c786cR59-R65 but I feel like noone would look at this issue then, afaik its still a bug D: [19:00:52] If you want to take a glance, the page in question is https://addshore-alpha.wiki.opencura.com/wiki/UptimeCheck [19:01:42] heh, I get a different content length in curl and in the browser [19:10:12] commenting out this line fixes the uptime check https://usercontent.irccloud-cdn.com/file/PNrarRTN/image.png [19:10:37] which is this line https://github.com/wikimedia/mediawiki/commit/4f11b614544be8cb6198fbbef36e90206ed311bf#diff-6a25b7d123e94e4ae53bd62ecb2ebac4d94d85090177605742bcfda53d3c786cR1011 [19:14:04] Written up as https://phabricator.wikimedia.org/T235554#6628446 [19:14:49] Will I cause "super bad things" by commenting out that line? or only apache blocking for longer waiting for PHP? [19:37:09] nope, seemingly started failing again