[12:29] bac benji danilos gmb: call in 1 [12:29] ack [12:30] ok [12:41] * benji goes to the utility drawer to find a nine volt battery to satiate this chirping smoke detector. [12:45] much better [13:37] gmb, do you have time to throw a drowning man a line? via Skype? :-) [13:40] gary_poster: Can you give me 10 minutes to just grab a drink? [13:40] sure gmb :-) [13:40] gary_poster: Cool. I'll ping you shortly. [13:40] thank you [13:49] gary_poster: Ready when you are [13:53] hi benji -- you free to chat? i've been looking for good ways to screen share, etc but have nothing [13:53] sure [13:55] gmb, sorry, missed that. calling... [13:56] benji: skype? [13:56] sounds good [13:58] benji: bin/test -vvt test_mark_duplicate_query [13:59] bin/test -vvt test_mark_as_duplicate_query [14:02] bin/test -vvt test_mark_duplicate_query_count [14:33] benji: pushed fixes to lp:~bac/launchpad/bug-813322-2 [14:34] benji: and the correct failing test is: bin/test -vvt test_mark_as_duplicate_query_count [14:35] bac: looking now [15:00] gmb, someone added something in the template that disables the expander if there are more than 10 bugtasks. The fields are still calculated, and rendered, but the expander is not drawn. That could be an easy thing to change. But... [15:00] what do you do if you actually need to change something for a bugtask in that collection? Doesn't that seem like a broken behavior--or is there a workaround? [15:00] It strikes me that I could improve this by doing the "draw the form on demand" after all. [15:01] That would make the big story more functional, and the small and big story faster [15:01] CHR === Ursinha` is now known as Ursinha === Ursinha is now known as Guest8410 === Guest8410 is now known as Ursula === Ursula is now known as Ursinha [15:13] And CHR is done! Happy day. [15:17] gary_poster: Sorry, completely missed the fact that Colloquy had disconnected... [15:18] * gmb reads backscroll [15:18] :-) np [15:20] gary_poster: Well, bug 1 is an example of this (I was wondering why the expanders went away; this explains it). If you click on any of the edit icons on the bug 1 bugtasks table you get redirected to the bugtask:+editstatus page. (i.e. exactly what used to happen before the expanders). [15:20] <_mup_> Bug #1: Microsoft has a majority market share Bug #1: Microsoft has a majority market share gary_poster: So essentially we degrade nicely already. Changing things so that all the unnecessary work isn't done shouldn't break anything, I expect. [15:22] gmb, ok so keep current behavior but don't do unnecessary Python work. cool [15:22] gary_poster: Indeed. And we can then (probably) punt on the "Make it nicer and then faster" work if we want to. [15:22] right gmb. That sounds like a win for everything except the future :-) [15:23] gary_poster: Indeed. And if the future involves the Yellow squad we may yet regret it :) [15:23] heh [15:23] cross that bridge then and all that :-) [15:23] ok I'll see if I can pull this off... [15:23] Righto. [15:24] gary_poster: Ping me if you need to pull at any weird threads on that code. [15:24] bac: I've found that just under 90% of the queries are generated by eight or nine repetitions of very similar sets of queries over and over [15:24] cool thanks gmb [15:24] benji: skype? [15:26] bac: http://paste.ubuntu.com/662731/ [15:44] gmb, one-line change makes code go from 6 seconds to 2 ;-) [15:44] Sweet. [15:44] gary_poster: Want me to review it? [15:45] Or are you going to do Other Clever Things. [15:45] ? [15:46] gmb, yeah thanks. Lemme see if I get this up quickly--I have stuff I need to clean up. No, I intend to run away at the mention of Clever Things--or at least walk on a treadmill at a stately pace. [15:47] Very wise. [15:53] bac: it looks like the repeats aren't identical, but they only vary by bug ID [15:55] benji: actually i see a lot of *identical* queries [15:55] let me paste [15:56] bac: are you logging the statement only or the parameters too, there are only about two dozen unique queries, but the parameters vary [15:58] benji: http://pastebin.ubuntu.com/662767/plain/ -- the numeric prefix is the number of times the query was seen [16:00] benji: i'm stepping out to get a bite to eat. [16:00] that is a lot of dupes; I'm dissapointed that there isn't some sort of caching scheme that keeps those from happening [16:00] k, I'm going to do the same in a while [16:00] benji: would love to talk to you about how we can accomplish that... [16:00] on the other hand, even if we got rid of all the dupes, that would still be 258 queries [16:11] that number is not unheard of [16:16] bac: (for when you get back), the call to Snapshot on line 1834 is responsible for 7 queries for each duplicate and the next line generates 3 more, so that's 10 queries per duplicate right there [16:16] that's in lib/lp/bugs/model/bug.py [16:19] wow, then the subscribers that are fired on the notify(event) line trigger 31 more queries (per duplicate bug) [16:22] gmb, https://code.launchpad.net/~gary/launchpad/bug724025/+merge/71076 when you are ready. I ended up implementing it with a view function rather than a one-line template change so I could add comments and such, but it is still pretty short. [16:22] gary_poster: Righto, looking now. [16:22] thank you [16:24] gary_poster: Good stuff. Approved. [16:25] \0/ DebBugs works again! [16:25] Let joy be unconfined. [16:25] :-) thanks gmb [16:25] np [16:28] lunch, and a bank visit, in triumph ;-) [17:27] benji: interesting [17:33] bac: if I skip creating the snapshot and firing the event (either of which may not be practicle) the test is down to 55 queries, of which 22 are updating bug heat [17:34] one thought would be to defer firing the object modified event until email sending time (or if we have a reasonable way to create jobs, queue up a job for it) [17:35] brb/caffeine [17:36] but the notify is what populates the database for the cronjob to later chew on [17:39] bac: I haven't looked at the subscriber, but I doubt it's very complicated, right? We could either just have a function that we call that records the fact that we need to fire the duplication event and that the email should be sent (or they could be two different flags, preferably) or we could fire a new event that has a subscriber that does what the aformentioned function would do [17:41] this is starting to get into the pattern of "if you know their request will succeed, just record the fact that the user asked for X and tell them it worked and then do X ASAP, but out of band with the web server" [17:41] which is a good pattern, but not one that we do much of, as far as I am aware [17:44] benji: the event -> db -> action chain is pretty convoluted. i'm not convinced the even mechanism really buys us much. but, in order to avoid db changes, i worked within that framework [17:44] benji: perhaps that was a bad decision [17:45] if you look at the diff of my branch it'll be clear the work that was done to close the loop. it was pretty minimal [17:45] it's conservative to fire an object modified event when you modify an object, but if none of the subscribers care (and we're not too worried about introducing subscribers that do care in the future) then we can skip that part [18:07] benji: but we do care, as the subscriber is the one who stuffs the deferred bug notification into the db [18:09] bac: right, but that's "our" subscriber, we can just call that code directly (no need for a subscriber) because we know we need it to happen now, the other subscribers may be less important (but I bet we still want them to run eventually) [18:09] I'm investigating other things, but a deferred execution model seems to fit this really well. [19:21] darn, benji is gone [19:21] well, gary_poster, i'll brag to you [19:21] I like bragging! go for it! [19:21] based on benji's suggestion i removed the Snapshot and the use of the event model [19:21] queries down from 467 to 91 [19:22] hah! wow! [19:22] and things still work, I take it? ;-) [19:22] not sure it *works* but that's a detail [19:22] lol [19:23] bac, but I assume the basics work of what you were doing before, so sounds very good so far :-) [19:24] yeah, i hope so [19:24] i'll verify it works now [19:24] cool, lemme know [19:24] i think Snapshot may be possessed [19:30] oooweeeeeeeoooooo [19:30] daylight come and me wan' go home [19:31] reposting [19:31] based on benji's suggestion i removed the Snapshot and the use of the event model [19:31] 15:21 [19:31] queries down from 467 to 91 [19:31] Good news everyone: routers work better with electricity. [19:31] lol [19:31] bac: cool! [19:33] benji, bac hasn't said whether it actually works yet though. He has another branch in which he has deleted the code tree and the query count has dropped even more. [19:33] bac: while sitting in the twighlight of my unpowered home I dug into the subscribers some more, the main culprit is add_bug_change_notifications [19:33] heh [19:34] yes, i determined postgres is the root of our problem [19:34] heh [19:34] heh [19:34] are either of you getting the smoke from the dismal swamp fire? [19:34] I can tell you that ZODB doesn't have these problems. It has *other* problems, but not these. [19:35] :-) [19:35] I haven't been outside since my morning bike ride and I didn't notice any then. [19:36] no smoke for me [19:36] "Great Dismal Swamp" is the perfect name for a swamp [19:36] next to the Really Big Mountain. [19:36] lol [19:36] which overlooks The Especially Wet Lake [19:37] lol, very nice [19:37] these seem like place names from The Princess Bride [19:43] the more I look at this, the more I think it's crying out for an async approach; we shoudl be doing all this work to figure out what changed and who cares after the actual request has finished [19:44] that's what bac is working towards, in the small [19:44] hmm, or a long-poll type thing, but we'd still run afoul of the timeout [19:45] yep [19:45] if we had a simple and reliable way to schedule work for later, I suspect we could fix lots of timeouts and otherwise slow pages with this particular hammer [19:45] The job system is the chosen hammer [19:46] I don't hink it is super simple [19:46] it's fairly reliable [20:02] * bac -> chr [20:09] gary_poster, benji: my changes *appear* to work when exercised via lp.dev. proper tests are now the focus. [20:09] cool [20:10] benji: did you do chr? there was practically nothing there [20:10] bac: nope, my power was out at the time and then I forgot [20:10] I'm glad there wasn't a backlog [20:13] cool [20:17] i am releasing myself on my own recognizance. be back later. [20:32] doesn't sound safe to me.