launchpad-dev team mailing list archive

[Ian Booth <ian.booth@xxxxxxxxxxxxx>]

Hi Raphaël

Speaking off the top of my head, not looking at the query or code etc:

I'm wondering if "owned branches" for example is really that difficult 
to compute? select count(*) from branch where owner = ?
I for one would still like to see this count. I think it's reasonable 
for people to expect to see how entities of whatever type they own, be 
it projects, branches etc.

Perhaps registered branches fall into the same category:
... where registrant = ?

I understand subscribed branches count would be more expensive with a 
join to the BranchSubscription table and possibly the fact we conflate 
subscription with visibility (although that's changing with the new 
disclosure work). So this count I think can be removed if it's too 
expensive to do and I personally don't see how the number is useful anyway.

On 08/11/11 19:36, Raphaël Badin wrote:
> Hi Launchpadders,
>
> I've been working on a fix to prevent the page
> https://code.launchpad.net/~ubuntu-branches from timing out.
>
> I've improved the situation slightly by using the data we *must* fetch
> from the DB to avoid a 1s query (in most cases, among which all the
> "pathological" ones).
>
> But the main improvement (suggested by lifeless) was done by changing
> the UI from:
> http://people.canonical.com/~rvb/prev_menu_branches.png to
> http://people.canonical.com/~rvb/new_menu_branches.png.
>
> We choose to do this because, after analysing the queries in details, it
> appeared that the volume of the data itself was the reason why the
> queries were heavy and we could found little room for properly improving
> the queries.
>
> Obviously the best way to improve a query is simply not to do it ;)… so
> we decided to see if avoiding to counts the {Owned, Registered,
> Subscribed}branches would significantly improve the page performance (as
> the oops reports suggested it would).
>
> I've hidden my work behind a FF (code.simplified_branches_menu.enabled)
> to be able to A/B test the improvements on qastaging without interfering
> with anyone. I know testing performance on qastaging is not very
> accurate but I figured that if the fix was good enough for the page not
> to time out on qastaging the perf on production would be simply better.
>
> With the old menu, it is impossible to load the page to load and here
> are the kind of oopses we get:
> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-06fabadb8b802665135e2f048d72e8ba
> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-e13505381303340a3d138501c0f14c3a
> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-51525de16620edd7a8c6c5ecfa64e39b
> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-e7b00379ecad43e9a36798e84a87fb7a
>
> With the new menu, the page loads all right (remember, this is on
> qastaging) but still takes a long time to be rendered (6.62, 6.51, 5.71,
> 6.65, 6.30 - these a actual numbers for the page to load). This is not
> ideal but the improvement is still serious.
>
> I think the improvement on a page that times out constantly is worth the
> change but you might have a different take on this since this involves
> simplifying the UI a bit (please note that the new display is a little
> bit more consistent with the bug menu:
> http://people.canonical.com/~rvb/current_bug_menu.png).
>
> (I you agree that this is worth the change I'll make the new menu the
> default and remove the FF.)
>
> R.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~launchpad-dev
> Post to     : launchpad-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~launchpad-dev
> More help   : https://help.launchpad.net/ListHelp