[00:00:14] legoktm: do you still use the sul-test box in labs for anything? [00:00:20] bd808: nope [00:00:30] k. I think I'll nuke it then [00:00:40] we've got a bunch of crufty old vms out there [00:14:04] ori: https://www.mediawiki.org/w/index.php?title=ResourceLoader%2FModules&type=revision&diff=1829239&oldid=1826755 documented :) [00:17:11] Deskana: Do you still need http://securepoll.wmflabs.org/wiki/Main_Page for anything (/me guesses no) [00:17:38] bd808: Nope, you can nuke the lot of those wikis. [00:17:53] bd808: Thanks! [00:20:18] legoktm: thanks! [00:20:19] http://graphite.wikimedia.org/render/?width=586&height=308&_salt=1439338798.361&target=MediaWiki.echo.overlay.median [00:20:38] obviously you want to let that accumulate some data before you jump to any conclusions [00:21:06] but yeah, that's kind of crazy [00:21:08] yeah, I'll take a look again tomorrow :) [00:21:20] i was tailing the logs to see the metrics as they were coming in [00:21:32] and this is what i was seeing: https://dpaste.de/FuvK/raw [00:21:50] :/ [00:22:20] mw.hook( 'ext.echo.overlay.beforeShowingOverlay' ).fire( $overlay ); [00:22:30] hook execution is synchronous IIRC [00:22:40] and i think i saw navpopups adding a handler to that [00:23:12] yeah: [00:23:13] mw.hook( 'ext.echo.overlay.beforeShowingOverlay' ).add( function($overlay){ [00:23:14] dynamicContentHandler( $overlay.find(".mw-echo-state") ); [00:23:16] }); [00:23:32] that's near the very the bottom of MediaWiki:Gadget-popups.js [00:23:50] on en [00:24:46] that could definitely be a part of the story [00:25:29] hmm, but most people don't have popups enabled :/ [00:28:20] there's a request to https://en.wikipedia.org/w/api.php?action=query&format=json&meta=notifications¬sections=alert%7Cmessage¬groupbysection=1¬messageunreadfirst=1¬format=flyout¬limit=25¬prop=index%7Clist%7Ccount&uselang=en&_=1439339186628 [00:28:33] when you click [00:28:54] 301ms for me, and i think the flyout doesn't get rendered until it comes back [00:30:28] yeah, that's the culprit [00:31:19] yeah, that's the request to get the flyout info [00:34:16] why is it so slow? [00:34:48] greg-g: Do you remember what https://wikitech.wikimedia.org/wiki/Nova_Resource:Incident-test.mediawiki-core-team.eqiad.wmflabs was for? wikitech says you created it [00:38:04] ori: probably multiple things, a) it has to make 2 db queries to fetch "alerts" and "messages" b) for each notification, the formatter uses a bunch of messages combined together to build html, and for each one it has to check the suppression status of the user/title/etc. which is more db queries... I'm currently working on making the formatter suck less, and there's an epic task about splitting alerts and messages into separate flyouts for (a). [00:39:42] legoktm: something else to investigate: EducationProgram binds hook handlers to Echo hooks [00:39:50] they are suspiciously prominent in the xenon logs [00:40:01] their specific hooks? [00:40:37] the 'BeforeCreateEchoEvent' hook runs on every request (in an ExtensionFunction) instead of lazy loading, which is another thing that's on my list of things to fix [00:41:35] https://github.com/wikimedia/mediawiki-extensions-EducationProgram/blob/master/includes/notifications/NotificationsManager.php#L70-122 [00:43:23] doesn't the API have some kind of forceprofile equivalent? [00:44:26] not that I'm aware of? that would be nice... [00:46:29] I have to run, thanks for looking into this ori :) [00:48:11] np [00:49:34] but yeah, this is crazy slow, we have to fix that [01:08:36] tgr: Looks like https://www.mediawiki.org/wiki/Reading/Strategy/Kickoff may be at least part of what you were asking about yesterday [01:09:57] When do each of the sub-teams then being their own sub-sub-strategy process to figure out how to interpret the results of the reading sub-strategy which was interpreted from the strategy? [01:10:11] Deskana: behave [14:41:41] bd808: it was probably to test out https://github.com/etsy/morgue (which I dn't think I got it up and running) [16:25:34] greg-g: can I kill that VM then? [16:26:38] bd808: yup [16:26:50] greg-g: btw, plz submit some good ones to https://github.com/danluu/post-mortems ! :) [16:27:04] oh we're on the list now [16:27:05] heh [16:27:15] neat [18:02:15] csteipp: besides the suppressed deletes issue and https://phabricator.wikimedia.org/T108101, do we have anything else security-review wise for wikidata query service? or once these are done we're good? [18:02:52] SMalyshev: Just the notice on wikidata, and merging the patch for cookies/cors. [18:02:56] Then we're done! [18:03:03] ok, cool, thanks. [18:03:32] now I need to figure out who's supposed to +2 that patch... ops? wikidata? [18:48:06] csteipp: https://github.com/minimaxir/big-list-of-naughty-strings :) [18:52:12] hey what happens if someone tries to make an article with hello​​​​​hi as the title? There are five zero-width spaces between hello and hi there :) [18:52:54] TIAS? I'd think we diallow zero-width spaces [18:54:47] ha! it crashes parsoid with a 503 as far as I can tell [18:54:59] try: https://wikitech.wikimedia.org/wiki/EventLogging/Testing/BetaLabs%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8BTest?veaction=edit [18:59:18] ok, nvm the 503, that seems to always happen regardless of the page title, I'll tell Subbu about it later [18:59:35] but, it turns out we let the empty spaces into the page title field, without stripping: [18:59:37] https://wikitech.wikimedia.org/wiki/EventLogging/Testing/BetaLabsTest?redirect=no [18:59:40] https://wikitech.wikimedia.org/wiki/EventLogging/Testing/BetaLabs%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8BTest [20:35:18] legoktm: https://gerrit.wikimedia.org/r/#/c/230236/ [20:42:31] 10MediaWiki-Core-Team, 10MediaWiki-General-or-Unknown, 7Performance: Investigate poor Hooks::run() performance in xhprof output - https://phabricator.wikimedia.org/T76677#1532617 (10aaron) a:5aaron>3None [23:09:54] 10MediaWiki-Core-Team, 5Patch-For-Review: ObjectCacheSessionHandler should avoid pointless writes in write() - https://phabricator.wikimedia.org/T88635#1533224 (10aaron) Should be fixed in 08039b2df44a2e83974d77fccba337a5d86cd854 (and monitored).