[03:19:39] TimStarling: why did you not simply bundle the API module with the Parsoid extension? [03:20:30] the Parsoid extension has an obsolete job queue based update system in it [03:20:58] just enabling the extension causes it to start communicating with a parsoid instance supposedly on localhost [03:21:23] yuck [03:21:29] it's not deployed on WMF and I think the long-term plan is to delete it [03:23:02] any preliminary results to share showing the gain from batching requests? [03:23:33] it probably improves things considerably, right? parsoid makes a bajillion API requests per parse [03:24:28] yes, it improves things considerably [03:25:02] I don't remember the exact numbers, I did the local testing more than a week ago [03:27:11] for parse operations, there's still some remaining overhead due to the need to clear the state in between items [03:28:03] which drops things like in-process DOM caches [03:29:58] but note that my patch also brings in imageinfo requests, which don't have setup overhead per request [03:30:09] so pages with lots of images should be orders of magnitude faster [03:30:52] well, I guess the factor is limited to 50 since that is the batch size [03:32:09] but in general, I would expect at least a 5x drop in HHVM CPU usage due to parsoid [03:33:05] big enough to see in ganglia [03:40:05] is that going to spare VisualEditor for having to make API requests to pageimages on initialization? [03:42:08] jeez, it's still really bad. 28 API requests to load [[en:Sweden]] in VE. [03:42:38] of which 24 are pageimages reqs [03:42:42] all of which include this in their response: [03:42:44] '{"warnings":{"main":{"*":"Unrecognized parameter: 'gpslimit'"},"query":{"*":"Formatting of continuation data has changed. To receive raw query-continue data, use the 'rawcontinue' parameter. To silence this warning, pass an empty string for 'continue' in the initial query."}}' [03:43:17] maybe VE could use the same API [03:43:39] or a similar API [03:43:41] in core [03:44:49] 70-90% of our traffic is SPDY now, so the overhead per request is smaller, and dividing the work into many small requests allows it to be parallelized better [03:45:26] it could still be an improvement though, it would take some experimenting [03:46:39] * ori files a bug for the warning [04:43:21] The Parsoid extension was already deleted [16:09:11] Krenair: got a sec for https://gerrit.wikimedia.org/r/#/c/230280/ ? [16:12:11] ori, do we know how much that'd improve time to firstpaint? [16:14:36] Krenair: no. The impact would probably be very small. It's part of a series of changes to make the amount of blocking CSS smaller. But what I can do is live-hack the change on testwiki so you can see the impact on UX of making the syntaxhighlighting CSS nonblocking. [16:15:25] already on it [16:16:05] background reading: https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-blocking-css [16:17:53] It's pretty quick to load [16:18:35] not noticeable if you have to scroll down to see the code block, as is likely the case on most wikipedia articles [16:22:02] * ori nods [16:22:27] and it's not visually disruptive for it to render a tiny bit late [16:22:41] it doesn't cause content to shift or anything [16:24:16] Have you asked Jon Katz what he thinks? [16:24:44] no. do you think we should? [16:25:57] Maybe [16:26:40] sure [18:52:52] [11:46] ori [2015-08-10 20:35:03] is that going to spare VisualEditor for having to make API requests to pageimages on initialization? [18:52:58] ori: I thought VE already batched those? But maybe I'm wrong [18:53:34] Also our initial attempt at solving that problem was to try to convince the Parsoid people to put the data we needed (which they already requested from imageinfo as well) into the HTML output, but I don't think that ever went anywhere [19:09:40] RoanKattouw: that sounds like one of the use cases for restbase providing separate metadata and content chunks [19:10:48] Hmm I guess so [19:10:56] This discussion was pre-RB so we didn't think about that [19:16:51] the other aspect is that features like the media viewer need similar info [19:17:55] fwiw, current Parsoid output includes attributes like this: data-file-width="2267" data-file-height="1612" [19:19:41] would this already allow you to load image infos only when a user interacts with a specific image? [19:22:49] Hopefully? [19:22:53] I've forgotten most of the details [19:23:23] But if those are the image's original dimensions (as opposed to its rendered dimensions) then the answer is probably yes [22:10:09] * AaronSchulz yays at working vagrant [22:11:31] bd808: all I needed was latest vagrant, testing build of virtualbox, some adapter fiddling in the GUI, manually mounting the shared dir, and then provisioning :) [22:11:49] * AaronSchulz awaits more Windows 10 fun [22:13:15] that sounds like "fun" [23:35:28] ori: is there a way to send timing metrics to graphite client-side? I'd like to measure how long it takes for us to render the echo flyout after the user clicks on the badge: https://phabricator.wikimedia.org/T56486 [23:35:56] yes, it's called statsv and it is shamefully lacking in documentation, which is my fault [23:36:10] let me give you an example to work from, sec [23:38:35] legoktm: https://github.com/wikimedia/mediawiki-extensions-MultimediaViewer/blob/master/resources/mmv/logging/mmv.logging.PerformanceLogger.js#L427 [23:39:02] and mw.track is just magic? [23:39:07] yeah [23:39:36] https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/master/modules/ext.wikimediaEvents.statsd.js#L43-59 [23:40:14] that code subscribes to all mw.track() calls that have timing.* or counter.* as their topic [23:40:30] thanks [23:40:31] formats the metric data into a query string and pings a special endpoint [23:41:40] then there's more magic that processes it and ships it to graphite [23:41:48] but you don't need to worry about any of that, it should Just Work™ [23:43:05] the nice thing about using mw.track() here is that Echo does not accrue an additional dependency [23:43:30] if there is no subscriber for that topic then the messages go nowhere, which is fine [23:49:45] TimStarling: could you review https://gerrit.wikimedia.org/r/#/c/230265/ at some point? [23:51:07] ori: does https://gerrit.wikimedia.org/r/#/c/230947/ look right? [23:51:38] just reviewed it [23:51:40] looks good otherwise [23:51:58] [16:51] RoanKattouw Oops sorry [23:51:59] [16:51] RoanKattouw Thanks for canceling my +2 ori [23:52:03] Helps when I say that in a channel ori is in :D [23:52:20] I knew about ve.now() but I didn't realize we had mw.now() [23:52:42] mw.whenigetaroundtoit() [23:53:21] ori: Hmm, why is mw.now() - Date.now() such a large number? [23:53:39] one is in microseconds [23:53:43] no [23:54:00] No, I checked the, their logs are very close, both 12.158 [23:54:22] UTC? [23:54:29] hah, I guess I've had this tab open for days [23:54:33] And the computer has been asleep [23:54:45] the difference is pretty small for me [23:54:45] So window.performance.now() probably hasn't advanced but the clock has [23:54:55] On a tab I opened today the difference is +/- 0.2 [23:55:03] well, I updated the patch :) [23:55:09] quiddity: mw.thereisnodeadline() [23:55:17] yeah [23:55:18] Also unlike Date.now, the values returned by Performance.now() always increase at a constant rate, independent of the system clock (which might be adjusted manually or skewed by software like NTP). [23:55:19] eventualism uber alles! [23:55:43] Right [23:55:52] But for me it's off by 12 hours, which I think is probably due to sleep mode [23:56:16] legoktm: why are you excluding the "// Make sure the overlay is visible" bit? [23:57:04] iirc that was for cologneblue only, but we should include that part [23:57:55] amended [23:59:09] legoktm: I can cherry-pick that for you if you like [23:59:18] yes please :) [23:59:22] my internet is being flaky again