[03:54:44] dpifke: yes it works now, I could see data in the graphs, great! [12:31:42] Oooops: https://www.catchpoint.com/press-releases/catchpoint-to-acquire-webpagetest-org [13:40:13] Looks like Pat Meenan was aqui-hired by Catchpoint to work on WPT [13:40:31] Hah didn’t see your message [13:40:46] I hope they don’t mess with the licensing [13:42:21] An open core WPT would suck [14:49:52] perf team FYI: this will be going live for group0 hopefully today: https://phabricator.wikimedia.org/T257527 [14:58:35] gilles: think it will be good for us. bad for the companies that built things on top of WPT :) But not sure, haven't seen anything from Catchpoint that been open source before. [15:00:22] Thinking hosting our own version will works fine. Running C:s version ... not so much since I guess all those probes are too small. [15:07:54] cdanis: neat! [15:08:21] AaronSchulz: Krinkle: please review this first draft, fix any mistakes and add any critical info: https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Active-active_MediaWiki [17:25:37] aye [19:32:41] Krinkle: re: T263049 I'm confused. since they're different origin domains, I don't think any connection multiplexing will happen, even on HTTP2... right? [19:32:42] T263049: Research and consider network connections made due to Event Platform - https://phabricator.wikimedia.org/T263049 [19:33:21] cdanis: upload.wikimedia and en.wikipedia multiplex, why not this one? [19:33:29] are you sure? [19:33:40] cdanis: no, I'm not. I think these are actually separate. [19:33:48] cdanis: we choose not to, I vaguely remember [19:34:00] but it's not becasuse of origins or anything [19:34:15] it's based on IP and cert groups afaik. [19:34:39] media files are useful to seperate or at least that's what we determined back then [19:35:07] H2 clients and servers have improved since the early SPDY days so could be worth revisiting [19:35:18] we definitely do see a non-trivial connection setup cost from u.wm.o currently [19:35:36] which is why we're working on pre-connecting that but it only mitigates it a little bit [19:35:45] for meta.wikimedia we don't have that problem currently [19:35:46] yeah, so text-lb (enwiki et al) and upload are definitely separate (different IPs) [19:39:37] ah okay -- https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/ and https://engineering.linkedin.com/blog/2019/connection-coalescing are decent starting points [19:40:18] I had read something else in the HTTP/2 spec just now that implied different origins might open a new connection, but, I think it was just a may [19:42:32] however given the above, I don't think that separate domains are a concern; but separate IP addresses for a different edge datacenter potentially are -- although the cases we're talking about here are for rare events and for things sent asynchronously [19:45:48] cdanis: there was a bug in firefox some years ago where it would re-use the connection sometimes when it shouldn't. I forget what it was exactly but it was something like, it re-using it if it resolved to the same IP even if it wasn't in the SNI list it got from the first conn, or maybe the other way around, where it would re-use based on the SNI list alone, even if a DNS query would tell it is meant to be served on a different IP. In [19:45:48] either case it's arguably confusing on our end. [19:45:54] I forgot who changed but it was resolved in the end [19:46:04] I tried to find it in our and their bugtracker but not coming up for me [19:46:52] I'm probably using the wrong keywords since I don't know exactly what's what in this area [19:47:53] https://bugzilla.mozilla.org/show_bug.cgi?id=1363451 [19:48:41] https://bugzilla.mozilla.org/show_bug.cgi?id=1222136 [19:48:45] https://bugzilla.mozilla.org/show_bug.cgi?id=1604286 [19:50:02] mostly these are bugs reported by people whose server configuration doesn't quite comply with the HTTP2 spec [19:50:21] there's also https://bugzilla.mozilla.org/show_bug.cgi?id=1049095 however, an actual vulnerability [20:00:45] right, so I guess we were one of those people and as usual firefox is the only one implementing the spec strictly so it worked fine everywhere else [20:01:06] (that is, WebKit and Chrome) [21:29:32] yeah, Firefox has the most aggressive coalescing implementation, AIUI [21:30:11] As we used to say in the VisualEditor team in 2012: Firefox, it's so fast, it doesn't even work. [21:31:04] at the time I believe that was about the parsing of data URIs in HTML streams [23:35:26] gilles: presumably from our new layout shift code https://phabricator.wikimedia.org/T263047 [23:35:32] I guess maybe some versions don't implememnt it fully [23:35:51] or maybe it's something less bad, like maybe sources can be genuinely empty? [23:57:29] Like an empty array, yeah [23:57:38] I’ll fix that first thing tomorrow morning