100s/1000s breaks +bug and +subscribe with SQL timeout
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Fix Released
|
High
|
Graham Binns | ||
Bug Description
This bug:
https:/
is timing out repeatedly, but the oopses (e.g. https:/
https:/
There are some quite large jumps between the query times: for example, 2.2 seconds between queries 13 and 14, another 2.6 between 14 and 15, 1.9 between 50 and 51, ... I have no idea what stage of rendering these correspond to.
The bug has a large number of duplicates (300+) but creating a bug with lots of duplicates locally isn't enough to reproduce the problem.
Related branches
- Gavin Panella (community): Approve (js)
- Brad Crittenden (community): Approve (code)
-
Diff: 255 lines (+122/-17)7 files modifiedlib/canonical/launchpad/javascript/bugs/bugtask-index.js (+60/-9)
lib/lp/bugs/browser/bug.py (+0/-6)
lib/lp/bugs/browser/bugsubscription.py (+14/-0)
lib/lp/bugs/browser/configure.zcml (+5/-0)
lib/lp/bugs/browser/tests/bug-subscription-views.txt (+40/-0)
lib/lp/bugs/templates/bug-portlet-subscribers.pt (+3/-0)
lib/lp/bugs/templates/bugtask-index.pt (+0/-2)
| Changed in malone: | |
| status: | New → Triaged |
| importance: | Undecided → High |
| tags: | added: bug-page |
| Graham Binns (gmb) wrote | #1 |
| Graham Binns (gmb) wrote | #2 |
| Changed in malone: | |
| assignee: | nobody → Graham Binns (gmb) |
| milestone: | none → 3.1.11 |
| Changed in malone: | |
| status: | Triaged → In Progress |
| Paul Sladen (sladen) wrote | #3 |
| Paul Sladen (sladen) wrote | #4 |
| Paul Sladen (sladen) wrote | #5 |
| summary: |
- bug timing out without much sql time + 100s/1000s breaks +bug and +subscribe with SQL timeout |
| Graham Binns (gmb) wrote | #6 |
| Diogo Matsubara (matsubara) wrote Bug fixed by a commit | #7 |
| Changed in malone: | |
| status: | In Progress → Fix Committed |
| Changed in malone: | |
| status: | Fix Committed → Fix Released |
I've seen this a couple of times with bug 131679, too (OOPS-1404EA298). In this case, it's more obvious to me that it's an dupe subscription problem. There's a jump between statement 137 (fetching the BugSubscriptions from dupes) and statement 138 (footling around with ValidPersonCache) of nearly 12 seconds.
Bug 131679 has 292 dupes which bring a grand total of 1061 extra subscriptions with them. The trouble is that the results set from the dupe subscription query get iterated over more than once in the code before they get displayed (see Bug.getSubscrip
I'm not entirely clear why all the subscribers' details are getting loaded with each page load, since we don't appear to display them any more unless you're viewing the page with a JS-enabled browser, in which case the subscribers list is loaded asynchronously anyway.
The simple way to solve this problem, then, is to find the piece of code that's getting the subscribers list unnecessarily and excise it.