Activity log for bug #787765

Date Who What changed Old value New value Message
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