=== e1th0r is now known as salchichon === salchichon is now known as e1th0r === e1th0r is now known as salchichon === salchichon is now known as ROLLOECARNE === ROLLOECARNE is now known as TUBOECARNE [04:57] === Top 10 Time Out Counts by Page ID === [04:57] Hard / Soft Page ID [04:57] 270 / 12 Archive:EntryResource:getBuildSummariesForSourceIds [04:57] 151 / 43 Person:+commentedbugs [04:57] 75 / 269 CodeImportSchedulerApplication:CodeImportSchedulerAPI [04:57] 58 / 230 BugTask:+index [04:57] 10 / 265 Distribution:+bugs [04:57] 7 / 63 Archive:+packages [04:57] 7 / 7 ProjectGroup:+milestones [04:57] 6 / 62 MaloneApplication:+bugs [04:57] 6 / 9 Archive:+copy-packages [04:57] 5 / 1 BugTask:+editstatus-page [04:57] lifeless: no mailing list ones :) [04:58] because we raised the timeout [04:59] hard_timeoutpageid:MailingListApplication:MailingListAPIView617000 [04:59] https://launchpad.net/+feature-rules [05:01] :( [05:01] I thought my fix would have fixed that [05:01] lifeless: it isn't in the top 10 statement counts any more [05:02] thats good [05:02] lifeless: worth checking, but we should be able to get rid of that exception [05:02] it may be that we can remove ... yeah [05:02] see what the ppr shows [05:02] check tomorrow [05:02] * thumper agrees [05:03] lifeless: I am a little upset though, I was hoping it whould have made some of the code import scheduler ones go away [05:03] but not [05:03] s/not/no [05:04] thumper: https://devpad.canonical.com/~stub/ppr/lpnet/latest-daily-pageids.html [05:04] thumper: it looks like its peaking at 10s now [05:05] thumper: so improved - yes. [05:05] I'm guessing it is a different call that is peaking [05:05] thumper: I think the big thing is getting it off of the one machine. [05:05] hence my desire for the method to be included in the pageid [05:05] thumper: about 0.01% of calls I'd say [05:05] Failed to discover an OpenID server? [05:05] thumper: I agree, definitely doit [05:05] thumper: hmmm, I saw that the other day [05:05] I think SSO is having trouble of some sort [05:06] * thumper feels a bid sad that he is on a work channel on Sunday afternoon :-| [05:06] * thumper leaves [17:28] morning [20:59] morning [21:05] morning [21:08] wallyworld: hi, I'm just moving, we can have a chat after that if you like [21:08] wallyworld: or do you have kid stuff to do? [21:09] thumper: i have school drop off in 30 minutes; that will tale 20 minutes or so; i can ping you when i'm back? [21:09] yep [21:09] ttyl [21:39] any soyuz folk around ? [21:46] lifeless: Hi. [21:50] hi [21:50] so I'm fixing the timeout [21:50] ArchivePublication injects itself into the code path for getBuilds [21:50] and this makes things slow. [21:50] there is a test that this works [21:50] but its being done 'to make things fast' - oh, the irony. [21:50] It makes things slow? [21:50] Nice. [21:50] How is it making things slow? [21:51] the API doesn't use ArchivePublication [21:51] https://bugs.launchpad.net/soyuz/+bug/662523 [21:51] <_mup_> Bug #662523: Archive:EntryResource:getBuildSummariesForSourceIds times out [21:51] Ah, the API timeout, I see. [21:51] so, I'm wondering whether, when the core is fast, if that delegate is still needed [21:51] or if I need to support the injection (hacky) because other layers will be impacted [21:51] I'm groupifying the code [21:51] Where's the injection? [21:52] gimme a minute to get the test passing and I'll push so you can see [21:52] lib/lp/soyuz/adapters/archivesourcepublication.py [21:52] getStatusSummaryForBuilds [21:52] Ahh, I see. [21:53] It should be fast enough if you rewrite it. It's only there to cache getBuilds and getUnpublishedBuilds. [21:56] Using saved push location: lp:~lifeless/launchpad/getBuildSummariesForSourceIds [21:57] rev 11878 should be there now [22:13] wallyworld: you back? [22:17] thumper: yep [22:17] wallyworld: shall we mumble? [22:17] already logged in [22:54] aahhhhhhhhhh [22:55] What have you fixed? [22:55] getBuildStatusSummariesForSourceIdsAndArchive calls getBuildsForSourceIds and getUnpublishedBuilds [22:55] getUnpublishedBuilds calls getBuildsForSourceIds [22:56] oh [22:56] and did I mention that we do a (potentially -huge-) set difference in python? :last line of getUnpublishedBuildsForSources [22:58] lifeless: That .difference is a Storm operation. [22:58] It's done in SQL. [22:59] ok, thats a relief. [22:59] But it totally sucks that you can't tel. [22:59] *tell* [22:59] I only know because I looked at the SQL and saw the EXCEPT. [22:59] so [23:00] we *still* end up doing the same thing twice [23:00] except more of its on the db server [23:00] I'll batch that up [23:00] Great. [23:00] and then call and end to this branch [23:02] I might be able to look at it after Thursday. [23:06] that would be sweet. [23:06] I think it will be approximately constant queries now [23:06] though I haven't reached the activation energy to write a test for that [23:06] Excellent. [23:06] I've just been refactoring as I read stuff [23:06] It's very easy to get carried away refactoring in Soyuz... [23:06] the core query is still going ot be slow (8.4 regression) [23:07] I'd really like to see: [23:07] - the adapter nuked [23:07] Now that we're more allowed to cache in model objects, sure. [23:07] - only one retrieval of the spph's (vs twice in my branch (or 3N in trunk)) [23:07] wgrant: caching isn't needed [23:08] wgrant: you can cache, but its not what was needed [23:08] ArchiveSourcePackageRelease may still be needed. [23:08] sure [23:08] theres a lot of refactoring to do [23:08] many single object methods to nuke [23:10] I wonder if we should strongly encourage query count tests for new APIs and views. [23:12] certainly [23:12] if you're writing something new, a query count test at the start is an awesome idea. [23:13] https://code.launchpad.net/~lifeless/launchpad/getBuildSummariesForSourceIds/+merge/40298 if you're interested in this branch [23:13] I was just looking for it. [23:13] Any chance you could ec2 https://code.edge.launchpad.net/~wgrant/launchpad/destroy-distroseries-lucilleconfig/+merge/38648? PQM testfix-rejected it twice last week. [23:14] what flags [23:14] oh [23:14] we're in testfix right now [23:14] what are the odds [23:14] Awesome. [23:15] 38 mins to go [23:15] that should have the fix from sinzui [23:15] Ah, sinzui's fix still hasn't made it through? [23:15] Right. [23:15] so [23:15] what flags do you want? [23:15] --no-qa? [23:15] --no-qa was what was used last time. [23:15] So sounds good. [23:16] ok, kicked it off [23:16] Thanks. [23:16] de nada [23:20] jelmer: when you get up; https://bugs.launchpad.net/soyuz/+bug/669676 still needs qa, and its blocking further deployments. [23:23] It's easy enough to QA that on qastaging like we did last week. [23:24] a bit more involved [23:24] given we're looking for race conditions [23:25] anyhow, we'll be only 4 days back once we deploy up to it [23:27] Hm. [23:28] I think that has a bug. [23:29] Yeah, it looks like it has the same bug that r11812 fixed.