[00:41:07] RainbowSprinkles: T157644 [00:41:08] T157644: Spikes in "Syntax Error: Top-level pages object is wrong type (null)" and "Syntax Error: Invalid XRef entry" errors in production - https://phabricator.wikimedia.org/T157644 [01:15:49] who has crat on mw.o? -- https://www.mediawiki.org/wiki/Project:Requests/User_rights/Community_Tech_bot [01:16:43] Yvette: ^ [01:27:18] Hi! [01:31:04] bd808: All set. [01:32:44] I looked at https://www.mediawiki.org/wiki/Project:Requests and Krenair seems to have handled most of them. [01:32:56] The other requests, I mean. [01:35:35] tgr: I assigned it to tto [01:50:51] Yvette: thanks [02:14:45] thanks legoktm[NE] [21:01:06] tgr: Where are those captcha stats triggered from btw? Presumably something that comes out of authmanager? [21:09:12] Reedy: log events [21:09:51] the stuff that ends up in the captcha log? [21:09:55] the code is in WikimediaEvents / AuthManagerStatsdHandler [21:10:09] the log channel is called 'authevent' I think [21:12:03] LoggerFactory::getInstance( 'authevents' )->info( 'Captcha submitted on login', [ [21:12:25] Interesting [21:12:27] that stuff, yes [21:12:32] I wonder how much use is in the old logging we have [21:12:50] Which is just doing [21:12:50] wfDebugLog( 'captcha', 'ConfirmEdit: ' . $message . '; ' . $this->trigger ); [21:13:16] well, captchas are shown on edit as well [21:13:23] Oh, yeah [21:14:12] Could we change that into using similar logging? Would they be considered auth events? [21:14:18] it'd be cool to evolve that one-off thing into some generic method of pinging statsd in a log event [21:15:08] just add 'metrics' => ['captcha.edit.display'] or something and then have something process that and ping statsd [21:15:18] does not seem terribly hard to do [21:16:00] write a monolog statsd handler in core, add it to all channels [21:17:52] * Reedy files https://phabricator.wikimedia.org/T157735 as a starting point [21:27:26] AaronSchulz: is there a way with filebackend stuff to store many files in one go? [21:27:34] rather than a for loop calling quickStore? [21:29:57] like doQuickOperations? [21:31:27] Aha [21:31:47] I presume that stops the overhead of creating/closing connections to swift etc? [21:31:55] well, not completely stops, but reduces? [21:41:49] normally using quickStore() will use keep-alive [21:42:14] if you do multiple thing in do*Operations, it will make a new set of connections, but do all the writes concurrently [21:58:07] Reedy: maybe it does re-connect always, given the curl_close() calls in MultiHttpClient. [21:58:12] * AaronSchulz looks at that some more [22:07:06] I don't mind fixing it by turning it into a doQuickOperations [22:07:19] I've added some instrumentation now, so we an get an idea of how long each part takes [22:36:33] Reedy: my initial comment was right [22:36:50] it reuses them in spite of curl_close since the curl_multi handle is cached [22:36:53] http://technosophos.com/2012/06/18/connection-sharing-curl-php-how-re-use-http-connections-knock-70-rest-network-time.html [22:37:21] doQuickOperations forces NO_REUSE due to some nagle slowness or something [22:43:02] So nothing to be gained by swapping? [22:43:14] Or, still is by concurrent writes?