Launchpad Bugs is slow to use/painful on slow internet connection

While some pages are unnecessary large (e.g. https://bugs.launchpad.net/ubuntu returns 373K HTML(!!)), that's not the only problem: Launchpad itself is also very slow at generating the pages.

I've reported bug 294658 on the <https://bugs.launchpad.net/ubuntu> HTML being so large, and bug 294656 on reducing the number of JavaScript libraries requested by every page (though that should be less of an issue because they're usually cached).

Normally, bugs are best reported about problems rather than solutions, because possible solutions for a problem are mutually exclusive and deciding on a solution requires developer thought or discussion.

With Launchpad performance, however, there are many things we can do to improve it, and almost all those things can and should be done independently. So it's not really useful to have an overall bug report of the form "Please make Launchpad faster".

So, instead please report individual bugs on individual techniques we can use to improve performance, and mark them with the "performance" tag. For example, if there is a particular form that should use XHR instead of a page reload, report an individual bug about that. Thanks!

Access from US West Coast shows consistently a page load time (PLT) of several seconds for almost every click. This is for PLT2, meaning after all files have been cached locally in my browser. Checking network traffic reveals that time to first byte accounts for over 90% of PLT. This suggests that Launchpads web server operates inefficiently.

Switching from HTTPS to HTTP would reduce round trips. For suggestions on how to improve performance use Visual Round Trip Analyzer from Microsoft at http://www.google.com/search?q=+Visual+Round+Trip+Analyzer+Download and read http://msdn.microsoft.com/en-us/magazine/dd188562.aspx

Invalid? Could you give a reason for this? Has launchpad suddenly started to "Suck less" in this regard? I still have lags of several seconds (or more) adding and removing Subscribers...
kk

And adding comments, I just discovered...

Montel, please add justification why you believe this bug as invalid. Performance is still miserable.

Status changed until a justification is provided.

I think this was originally invalid from mpt, but I'm leaving triaged just to stop the noise on this bug. In practice, it will be hard to ever actually fix this bug. Smaller bugs detailing specific performance issues we can actually fix would be better and could actually be fixed then. A bug collecting a list of smaller bugs is also not useful just based on how the bugs team works and also because we don't have actual bug dependencies/relationships that make this workflow

I just found this via google because I just filed a bug and it was, as usual, a very painful experience.

It just feels very 'laggy' to do anything on launchpad. Not just following links, but just being on the site looking at a bug report. Scrolling up and down feels like my whole machine is under heavy load, while the hard drives are doing filesystem checks in the background. I am sometimes afraid my browser will just crash and take with it all those precious little pieces of information that I tediously collected over hours and hours of waiting for launchpad links to show up in my browser.

Ok, I am exaggerating. But compared to other sites there are not many that can rival launchpad.net in its suckiness.

I'm going to mark this bug as invalid *because* there is nothing code related in this bug : its all in separate more targeted bugs.

This search:
https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout

will return all of our most critical performance bugs. Pages that timeout *sometimes* will often be slow even when they don't timeout.

We have some capacity issues in the data centre - these don't require code changes and thus aren't appropriate as bugs. Additional hardware to resolve those capacity issues *has* been ordered and will come online in the next couple of weeks. Those capacity issues lead to in-datacentre queuing of requests : so something that renders in 0.5s may still take 2 seconds to get to you. Right now (as I write this) we have no such queuing, but sunday has considerably less traffic than monday.

Our 99th percentile render time has dropped was 2.5 seconds late last week - across all pages and services, but some pages are slower - we're tracking fixing that as we fix the aforementioned critical performance bugs.

@andreas if your bug filing issue is not covered by the timeouts - (and I think it is: the '+filebug' timeouts are all about bug filing issues) - please file a *new* bug describing the experience you had, so we can analyse what caused the problem and fix it for you.