Please improve performance of launchpad.net

Bug #305630 reported by Daniel Hahler on 2008-12-05
114
This bug affects 17 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Undecided
Unassigned

Bug Description

Please throw more hardware at launchpad.net _and_ profile/optimize the existing applications to improve overall performance.

Page loading times are quite important for web applications and launchpad.net in general is too slow.

I'm using mostly bugs.launchpad.net, but e.g. code.launchpad.net could be a lot snappier, too.

IMHO no page should take longer than 2 seconds to load.

Some suggestions:
 - only serve one CSS and one JS file per page.. with all the CSS and JS bundled together.
 - improve caching of media files (images, css, js), which are handled different in (some?) browsers IIRC
 - do not display overly long tag lists
 - profile applications
 - add more servers

I've found the meta bug, which mentions some of the problems already, again: bug 106452.

TAC one (tacone) wrote :

While the CSS and JS tip is good, I don't think that's what you're really looking for. Launchpad seems to serve those files very fast, to me.
It feels slow only in the preprocessing stage. Query caching would help, but that's not easy on complex applications like launchpad.

Pierre Slamich (pierre-slamich) wrote :

I've read that an Ajaxy UI is planned which should improve perceived snappiness

Ryan Rushton (ryancr) wrote :

Took a quick look in Firebug, seems it must be in the preprocessing stage:

Initial GET request:

This page:
23KB @ 4.8s

Planet Ubuntu:
199KB @ 373ms

*both pages refreshed with a Ctrl-F5

Scott Kitterman (kitterman) wrote :

At the bottom of each page source is a comment about the data base query part of loading the page. For this page I got:

<!-- at least 461 queries issued in 4.10 seconds -->
<!-- Launchpad 2.1.11 (r7322) -->

That seems like both a lot of queries and a lot of time.

Bryce Harrington (bryce) on 2008-12-06
Changed in launchpad:
status: New → Confirmed
Bryce Harrington (bryce) wrote :

The performance issues could also be disguised a bit better by reducing number of roundtrips required for particular use cases.

For instance, when I'm doing bug triage, my flow goes something like this:
1. Click link to load page (wait...)
2. Review bug
3
. Click on an attached log to get some bit of data like which driver was used (loads quick)
4. Click back button to return to bug (wait... why doesn't this just pull instantly from the browser cache??)
5. Click on "edit description/title" (wait...)
6. Add the driver name to the title. Or paste in backtrace info. Click save (wait...)
7. Update the status/importance and leave a comment. Click save (wait...)
8. Move to next bug

If launchpad performance was improved by 20%, let's say, then my wait time would be reduced from 5 wait units to 4 wait units

But imagine instead that the workflow was adjusted so I could update the title from the main bug page rather than go to a separate page. That eliminates 2 waits (steps #5 and #6), so without changing launchpad at all, I've gone from 5 wait units to 3 wait units.

Just as a workaround, i've found that having a dns cache can make (and does make, here) launchpad faster. Without that, the usual load time for pages is 8+ seconds. Be greatful it isn't 40+ seconds again!

Geir Ove Myhr (gomyhr) wrote :

My workaround for minimizing the wait time is to work in parallel. My version of Bryce's work flow is
0. Right click on bug and select "Open in new tab" for 10-15 bugs (the first pages load while the next ones are selected)
1. Click on the first tab (no wait)
...
3. Open attached log in separate tab
4. Close the tab when done (avoids waiting for "Back")
...
7. Click save after doing the final action on a bug (don't wait)
8. Move to next bug on next tab
...
End of round or after next bug: Go back and check that no error occured and close the tab.

This eliminates 3 of the waits above. I don't always do 3-4 and 7-8 like that, but always 0-1.

Ryan wrote:
> Initial GET request:
>
> This page:
> 23KB @ 4.8s
>
> Planet Ubuntu:
> 199KB @ 373ms

Note that https requires more network round trips to set up the SSL connection
(at least 2, IIRC). So network latency has a larger effect on https connections
than on http connections, and launchpad.net serves most things via https.

Daniel Hahler (blueyed) on 2008-12-09
description: updated
papukaija (papukaija) wrote :

Do we really need the https for every page?

KarlGoetz (kgoetz) wrote :

I was going to file a bug on the number of tags getting displayed (in relation to Ubuntu specifically). Simply displaying all tags > 1 would reduce the list by orders of magnitude.
Should I file that bug separately, or simply leave this comment here?
On my laptop (which isn't exactly fast) Launchpad burns up the ram/cpu time like no other bts i've used (i think the only thing it struggles with more is Google maps, which has/should have considerably more data loading).

Matthew Paul Thomas (mpt) wrote :

Please report individual bugs on individual performance techniques, and mark them with the "performance" tag. See my comment in bug 106452 for further explanation. Thanks!

Matthew Paul Thomas (mpt) wrote :

For example, using HTTP instead of HTTPS is bug 46591, and reducing the number of tags displayed on Ubuntu's bugs page is bug 310693.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions