September 25, 2012

Launchpad blog
lp-blog
Launchpad blog
Launchpad JavaScript now combo loaded and faster than ever.

Network graph of the combo loaded JavaScript.

Updated network graph

Back in January a side project was started to update the JavaScript used in Launchpad. Launchpad has been using YUI 3.3.0 for a long time, very successfully, however recent advances in YUI 3.5 and higher have added some great tools for development that Launchpad can take advantage of. In order to facilitate easier upgrades our YUI library version Launchpad has been moved to using a combo loader for serving out JavaScript.

This means, that instead of a single launchpad.js file that can be upwards of 3MB in size, each request builds a list of JavaScript modules needed for the current page to work, and the combo loader only sends down those modules. This drastically cuts down on the download size of the JavaScript for users. These combo loaded JavaScript files are also cached for speedy serving to other users of Launchpad.

The combo loader also allows us to specify which YUI version to load via a tweak to the url. In this way we can easily test new version of YUI side by side with the current stable version as they come out. This allows Launchpad to keep with future YUI released much faster.

We’re excited that today Launchpad has moved from YUI 3.3.0 to 3.5.1 and is now served by the combo loader. This change provides a faster experience for users along with easier maintenance and new JavaScript library features for developers.

We’ve still got more to do though. YUI just released version 3.7 and we aim to push that into production faster than ever before. Please let us know how these changes work for you.

Launchpad also wants to thank the folks over at YUI for continuing the great work on a tool that Launchpad heavily depends on.

September 24, 2012
Parallel testing is live

One of the projects the Launchpad Squads (yellow) have been working on has been the Parallel Testing during the last cycle, this has now been completed and is now in operation. WebOps have today finished setting up parallel testing in buildbot. Buildbot-poll has been updated to know about the new builders, and the developers have  confirmed that [testfix] and automatic stable merging etc. work fine. Nothing should have changed except that builds now take 35 minutes rather than 6.5 hours.

If something goes wrong, http://lpbuildbot.canonical.com/waterfall and https://dev.launchpad.net/yellow/ParallelTestingTroubleshooting may be helpful. The buildbot master is still praseodymium, but the slaves are new: sluagh for devel, and radande for db-devel. If you need packages upgraded on the slaves, poke WebOps as before.

If you would like to follow the discussion on this topic you’ll find more on the Launchpad development mailing list

September 16, 2012
Launchpad Builders update

We have recovered some of the affected builders, more will be coming back on later this week with the remainder to come in a few weeks when we have new hardware.  Until then launchpad builders will be at a reduced build capacity. l

We apologise for the inconvenience and we’re sorry for the disruption to your service.

November 10, 2011
Improved performance for personal code pages

Edit 2011-11-15 08:18 UTC: The problem is now fixed and we’ve re-enabled the new menu.

Edit 2011-11-11 13:42 UTC: We’ve temporarily disabled the new menu while we fix some unfortunate side effect.

We’ve just deployed a new, simplified version of the branch menu displayed on the right hand side of personal code pages (e.g. personal page for the Launchpad team). It looks like this:

Old menu

New menu

Calculating the number of branches took way too much time for people/teams with a huge number of branches (e.g. https://code.launchpad.net/~ubuntu-branches), up to the point that they were getting timeouts.

The new design, along with optimisations we’ve made to the database queries, should improve performance for everyone.

May 12, 2011
Launchpad Answers is faster

Users of Launchpad Answers will see that asking a question, editing it, or posting a comment to it is faster. Email about question changes is sent a few minutes latter. Many bugs relating to question emails were fixed as we moved the work of sending emails to the new process.

Users and answer contacts saw slow pages or time out errors when working with questions in large projects. Simple actions like asking a question or providing an answer would fail. It was common to see errors converting bugs into questions. A few weeks ago, we saw that 8 of the top 10 kinds of time outs involved questions; though this ratio was caused in part by the tremendous work of making other parts of Launchpad faster.

The root cause of the slow question pages was sending email to all the subscribers before showing the next page. The solution was to queue the the event to notify subscribers, and send the emails later. While updating the code, there were many opportunities to fix related Answers bugs. I am particularly pleased with the changes to the rules to create a question. There were four lines of code, and while I intended to fix one line, I realised there was a bug related to each line of code. In a matter of minutes I had fixed four bugs. The most obvious change you will see is that question emails will now state that you received the email because you asked the question, where previously you were merely described as a subscriber.

April 19, 2011
What you said: faster pages or more accurate bug counts

Last week I asked what you’d prefer: faster loading pages that may have slightly inaccurate bug counts or slower loading pages where the bug counts were guaranteed to be accurate always.

Well, here’s the result:

85.9% of respondents wanted faster pages

85.9% of the people who responded to the question said they wanted faster pages, even if it meant that some of the bug counts might be a little inaccurate.

I asked a similar question on Facebook and 88% of the people who replied said they’d rather have faster pages.

We’re not going to do anything just yet. First, we want to do some more research. If we did implement this, though, it’s likely to affect only those projects with private bugs and, even then, show up only in side-boxes such as this:

Bug information box

There’s more in the full discussion on the launchpad-dev list.

July 14, 2010
Three tips for faster launchpadlib api clients

Three tips from Leonard’s lightning talk in Prague about writing faster Launchpadlib API clients:

1. Use the latest launchpadlib. It gets faster from one release to the next. (The versions in the current Ubuntu release should be fine; otherwise run from the branch or the latest tarball.)

2. Profile:

    import httplib2
    httplib2.debuglevel = 1

will show each http request and response, so that you can see what’s taking time.

3. Fetch objects only once:

Don’t do this:

    if bug.person is not None:
        print bug.person.name

instead

    p = bug.person
    if p is not None:
        print p.name

In the first case, the client may fetch the Person object twice. (We may fix this in future.)