2011-05-24 19:44:06 |
Cody A.W. Somerville |
bug |
|
|
added bug |
2011-05-24 20:23:18 |
Gavin Panella |
launchpad: status |
New |
Triaged |
|
2011-05-24 20:23:20 |
Gavin Panella |
launchpad: importance |
Undecided |
Critical |
|
2011-05-25 01:22:31 |
Robert Collins |
summary |
Project series page can timeout |
ProductSeries:+index timeouts |
|
2011-05-25 01:32:39 |
Robert Collins |
description |
Attempting to access the page for a series on a project can timeout; https://launchpad.net/bugsy/development/ continuously times out for me. This makes it rather difficult to add new milestones.
Here is a few of the OOPs:
OOPS-1970DT594
OOPS-1970AX602
OOPS-1970J656 |
Attempting to access the page for a series on a project can timeout; https://launchpad.net/bugsy/development/ continuously times out for me. This makes it rather difficult to add new milestones.
Here is a few of the OOPs:
OOPS-1970DT594
OOPS-1970AX602
OOPS-1970J656
The oopses consistently show very high python time:
SQL time: 1221 ms
Non-sql time: 7942 ms
Total time: 9163 ms
Statement Count: 103 |
|
2011-05-25 01:40:12 |
Robert Collins |
description |
Attempting to access the page for a series on a project can timeout; https://launchpad.net/bugsy/development/ continuously times out for me. This makes it rather difficult to add new milestones.
Here is a few of the OOPs:
OOPS-1970DT594
OOPS-1970AX602
OOPS-1970J656
The oopses consistently show very high python time:
SQL time: 1221 ms
Non-sql time: 7942 ms
Total time: 9163 ms
Statement Count: 103 |
Attempting to access the page for a series on a project can timeout; https://launchpad.net/bugsy/development/ continuously times out for me. This makes it rather difficult to add new milestones.
Here is a few of the OOPs:
OOPS-1970DT594
OOPS-1970AX602
OOPS-1970J656
The oopses consistently show very high python time:
SQL time: 1221 ms
Non-sql time: 7942 ms
Total time: 9163 ms
Statement Count: 103
Things to look at:
* per-driver / milestone owner code paths
* get cody to generate a profile on https://qastaging.launchpad.net/++profile++show/bugsy/development |
|
2011-05-25 02:00:23 |
Robert Collins |
description |
Attempting to access the page for a series on a project can timeout; https://launchpad.net/bugsy/development/ continuously times out for me. This makes it rather difficult to add new milestones.
Here is a few of the OOPs:
OOPS-1970DT594
OOPS-1970AX602
OOPS-1970J656
The oopses consistently show very high python time:
SQL time: 1221 ms
Non-sql time: 7942 ms
Total time: 9163 ms
Statement Count: 103
Things to look at:
* per-driver / milestone owner code paths
* get cody to generate a profile on https://qastaging.launchpad.net/++profile++show/bugsy/development |
Attempting to access the page for a series on a project can timeout; https://launchpad.net/bugsy/development/ continuously times out for me. This makes it rather difficult to add new milestones.
Here is a few of the OOPs:
OOPS-1970DT594
OOPS-1970AX602
OOPS-1970J656
The oopses consistently show very high python time:
SQL time: 1221 ms
Non-sql time: 7942 ms
Total time: 9163 ms
Statement Count: 103
Things to look at:
* per-driver / milestone owner code paths
* get cody to generate a profile on https://qastaging.launchpad.net/++profile++show/bugsy/development
15 0 7.6386 0.1779 lp.bugs.browser.structuralsubscription:431(expose_user_administered_teams_to_js)
+64305 0 4.1135 0.7071 +canonical.database.sqlbase:240(__eq__)
+795 0 0.7276 0.0290 +canonical.launchpad.webapp.publisher:465(canonical_url)
+2130 0 1.3259 0.0115 +storm.sqlobject:522(__iter__)
+795 0 0.9399 0.0064 +zope.traversing.browser.absoluteurl:34(absoluteURL)
+795 0 0.0193 0.0031 +lp.registry.model.person:1619(title)
+795 0 0.0011 0.0011 +<method 'append' of 'list' objects>
+15 0 0.0026 0.0004 +lp.registry.model.person:2312(teams_participated_in)
+15 0 0.0003 0.0003 +<method 'providedBy' of '_interface_coptimizations.SpecificationBase' objects>
+15 0 0.2975 0.0001 +lp.services.propertycache:109(__get__)
+30 0 0.0330 0.0001 +zope.site.hooks:93(adapter_hook)
drilling in:
67563 0 4.1408 0.7228 canonical.database.sqlbase:240(__eq__)
+190530 0 3.2106 1.3876 +storm.properties:51(__get__)
+135126 0 0.2074 0.2074 +<zope.security._proxy.getObject>
195453 0 3.3104 1.4272 storm.properties:51(__get__)
+195453 0 1.0463 0.7612 +storm.properties:84(_get_column)
+195395 0 0.4867 0.4779 +<method 'get' of 'storm.variables.Variable' objects>
+195395 0 0.3503 0.3503 +<storm.cextensions.get_obj_info>
So death-by linear-lookups in expose_user_administered_teams_to_js |
|
2011-05-25 02:06:02 |
Robert Collins |
tags |
oem-services timeout |
oem-services regression timeout |
|
2011-05-25 02:16:01 |
Robert Collins |
description |
Attempting to access the page for a series on a project can timeout; https://launchpad.net/bugsy/development/ continuously times out for me. This makes it rather difficult to add new milestones.
Here is a few of the OOPs:
OOPS-1970DT594
OOPS-1970AX602
OOPS-1970J656
The oopses consistently show very high python time:
SQL time: 1221 ms
Non-sql time: 7942 ms
Total time: 9163 ms
Statement Count: 103
Things to look at:
* per-driver / milestone owner code paths
* get cody to generate a profile on https://qastaging.launchpad.net/++profile++show/bugsy/development
15 0 7.6386 0.1779 lp.bugs.browser.structuralsubscription:431(expose_user_administered_teams_to_js)
+64305 0 4.1135 0.7071 +canonical.database.sqlbase:240(__eq__)
+795 0 0.7276 0.0290 +canonical.launchpad.webapp.publisher:465(canonical_url)
+2130 0 1.3259 0.0115 +storm.sqlobject:522(__iter__)
+795 0 0.9399 0.0064 +zope.traversing.browser.absoluteurl:34(absoluteURL)
+795 0 0.0193 0.0031 +lp.registry.model.person:1619(title)
+795 0 0.0011 0.0011 +<method 'append' of 'list' objects>
+15 0 0.0026 0.0004 +lp.registry.model.person:2312(teams_participated_in)
+15 0 0.0003 0.0003 +<method 'providedBy' of '_interface_coptimizations.SpecificationBase' objects>
+15 0 0.2975 0.0001 +lp.services.propertycache:109(__get__)
+30 0 0.0330 0.0001 +zope.site.hooks:93(adapter_hook)
drilling in:
67563 0 4.1408 0.7228 canonical.database.sqlbase:240(__eq__)
+190530 0 3.2106 1.3876 +storm.properties:51(__get__)
+135126 0 0.2074 0.2074 +<zope.security._proxy.getObject>
195453 0 3.3104 1.4272 storm.properties:51(__get__)
+195453 0 1.0463 0.7612 +storm.properties:84(_get_column)
+195395 0 0.4867 0.4779 +<method 'get' of 'storm.variables.Variable' objects>
+195395 0 0.3503 0.3503 +<storm.cextensions.get_obj_info>
So death-by linear-lookups in expose_user_administered_teams_to_js |
Summary
=======
A quadratic-in-teams scaling function was added during the new subscriptions work. This regressed page performance on pages that trigger expose_user_administered_teams_to_js. Additionally this page itself is running the function multiple times due to this call stack:
lp.registry.browser.milestone:212(initialize)
expose_structural_subscription_data_to_js
expose_user_administered_teams_to_js
So each milestone view created is running the function and the function is slow (foo in a-list triggers quadratic lookup overhead). Fixing the repeated-invocations should provide significant amelioration.
Details
=======
Attempting to access the page for a series on a project can timeout; https://launchpad.net/bugsy/development/ continuously times out for me. This makes it rather difficult to add new milestones.
Here is a few of the OOPs:
OOPS-1970DT594
OOPS-1970AX602
OOPS-1970J656
The oopses consistently show very high python time:
SQL time: 1221 ms
Non-sql time: 7942 ms
Total time: 9163 ms
Statement Count: 103
Things to look at:
* per-driver / milestone owner code paths
* get cody to generate a profile on https://qastaging.launchpad.net/++profile++show/bugsy/development
15 0 7.6386 0.1779 lp.bugs.browser.structuralsubscription:431(expose_user_administered_teams_to_js)
+64305 0 4.1135 0.7071 +canonical.database.sqlbase:240(__eq__)
+795 0 0.7276 0.0290 +canonical.launchpad.webapp.publisher:465(canonical_url)
+2130 0 1.3259 0.0115 +storm.sqlobject:522(__iter__)
+795 0 0.9399 0.0064 +zope.traversing.browser.absoluteurl:34(absoluteURL)
+795 0 0.0193 0.0031 +lp.registry.model.person:1619(title)
+795 0 0.0011 0.0011 +<method 'append' of 'list' objects>
+15 0 0.0026 0.0004 +lp.registry.model.person:2312(teams_participated_in)
+15 0 0.0003 0.0003 +<method 'providedBy' of '_interface_coptimizations.SpecificationBase' objects>
+15 0 0.2975 0.0001 +lp.services.propertycache:109(__get__)
+30 0 0.0330 0.0001 +zope.site.hooks:93(adapter_hook)
drilling in:
67563 0 4.1408 0.7228 canonical.database.sqlbase:240(__eq__)
+190530 0 3.2106 1.3876 +storm.properties:51(__get__)
+135126 0 0.2074 0.2074 +<zope.security._proxy.getObject>
195453 0 3.3104 1.4272 storm.properties:51(__get__)
+195453 0 1.0463 0.7612 +storm.properties:84(_get_column)
+195395 0 0.4867 0.4779 +<method 'get' of 'storm.variables.Variable' objects>
+195395 0 0.3503 0.3503 +<storm.cextensions.get_obj_info>
So death-by linear-lookups in expose_user_administered_teams_to_js |
|
2011-05-26 08:05:36 |
Launchpad Janitor |
branch linked |
|
lp:~lifeless/launchpad/bug-787765 |
|
2011-05-27 04:20:26 |
Launchpad QA Bot |
launchpad: assignee |
|
Robert Collins (lifeless) |
|
2011-05-27 04:20:27 |
Launchpad QA Bot |
tags |
oem-services regression timeout |
oem-services qa-needstesting regression timeout |
|
2011-05-27 04:20:28 |
Launchpad QA Bot |
launchpad: status |
Triaged |
Fix Committed |
|
2011-05-27 05:18:49 |
Robert Collins |
tags |
oem-services qa-needstesting regression timeout |
oem-services qa-ok regression timeout |
|
2011-06-01 12:39:05 |
William Grant |
launchpad: status |
Fix Committed |
Fix Released |
|
2011-09-16 19:36:33 |
Francis J. Lacoste |
tags |
oem-services qa-ok regression timeout |
critical-analysis oem-services qa-ok regression timeout |
|