[15:50:44] * guillom waves. [18:20:31] slow [19:22:52] Helder: the rscore gadget looks very interesting, but doesn't seem to work with nav popups yet... [19:23:06] worth filing an issue on github? [19:24:09] a user from ptwiki reported the same problem [19:24:29] I didn't test popups in a while, though [19:26:02] i could imagine that many people will want to use both tools together [19:26:37] is it about the Popups gadget or the popups beta feature? [19:27:30] https://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_popups [19:28:17] the beta feature (now in production on some wikis) is called hovercards, and is more aimed at general readers, popups is more a power user tool [19:28:27] (like rc patrollers) [19:30:49] HaeB, it seems to be a problem on https://en.wikipedia.org/wiki/MediaWiki:Gadget-popups.js [19:31:39] It has a test 'if (document.readyState=="complete")', which happens to be false until the requests from the scorer are finished [19:31:52] so it is waiting until that happens to be loaded [19:32:03] (not sure why) [19:35:12] you're right, it seems that popups start working after all the scores have loaded [19:36:32] "// For some reason popups requires a fully loaded page" [19:37:02] heh [19:38:00] so i guess the issue will solve itself once wmflabs.org has instant-like performance ;) [19:39:49] yeah, I assume so [19:42:41] hehe :D [19:44:35] HaeB, for the record, that is reported on https://github.com/halfak/Objective-Revision-Evaluation-Service/issues/26 [19:45:44] I bet we can tune it to soup up performance once you guys have it better settled :D [19:45:58] nginx / varnish -> uwsgi + caching [19:46:06] and if it’s stateless spread it across a few machines and load balance [19:46:18] halfak: ^ you know I’m up for that whenever you think it’s needed, right? [19:47:18] YuviPanda, yes. This is going to be a pressing issue. [19:47:29] halfak: how stateless are these things? [19:47:33] It is stateless, but the major bottleneck is latency with the API. [19:47:35] and if they have state where is the state stored in? [19:47:37] aaaahhhhhhhh [19:47:46] like, network latency or the API being shit? [19:47:53] I think I can do some things with batching. [19:47:57] network latency. [19:48:05] Well. a little of both. [19:48:06] hmm, they’re basically in the same datacenter. [19:48:16] so I’d suspect it’s more of the latter... [19:48:30] If I could say, "get me this revision, and it's parent, and some info about the user and the first revision to this page" in one request. [19:49:03] The problem is that I have to request the revision to figure out what the parent revision is and who the user is and what page the edit was to. [19:49:11] So I fire 5 API requests for each revision. [19:49:14] are you caching those? [19:49:21] YuviPanda, no caching yet. [19:49:21] I guess revision info doesn’t change [19:49:37] One thing I'd like to do is batch the requests. [19:49:48] right [19:49:53] but I think caching is a must at some point [19:50:05] So if you request scores for a large number of revisions, I'll retrieve all of the metadata I can as a block and use dependency injection [19:50:10] YuviPanda, +1. [19:50:12] anyway, in terms of architecture just remember to keep the stateful parts / stateless parts separate enough [19:50:18] and then we can scale those appropriately :) [19:50:21] YuviPanda, there is no state [19:50:26] :) [19:50:27] well there will be! [19:50:29] with cache :) [19:50:37] Cache isn't really state. [19:50:40] Is it? [19:50:48] it needs to be scaled differently, but yeah [19:50:50] I mean, it shouldn't affect behavior -- just performance. [19:50:50] not necessarily [19:50:58] but: if we killed all caches in prod [19:51:04] everything will melt in like 5 seconds [19:51:06] The state wouldn't change :) [19:51:20] so it’s important ot keep cache in mind when building things that need to scale :D [19:51:22] Except for the state of our sanity. [19:51:30] indeed [19:51:31] YuviPanda, as we have :) [19:51:35] yup! :) [19:51:41] But you don't optimize until you know you need it. [19:51:43] yeah [19:51:45] totally [19:52:03] We're bumping up against performance issues. [19:52:23] So we need to get it worked out soon. [19:52:42] One thing that has a massive performance effect is looking up misspelled words. [19:52:52] That one is actually CPU intensive. [19:53:10] I haven't documented that and written up a bug yet. [19:53:20] I strongly suspsect that NLTK's internals aren't using a hash lookup. [19:53:42] :) [19:53:42] so it's N or worse complexity depending on the dictionary [19:53:59] profile!! [19:54:11] YuviPanda, I know where the hot spot is. [19:54:18] I just haven't found a good alternative yet. [19:54:34] Anyway, I've got to run now, but I would really like to talk scaling soon. I can have some notes together on problems and opportunities tomorrow morning. [19:56:13] halfak: sweet [20:03:05] * halfak runs away [20:03:10] have a good Saturday!