LP package accept U/I timeouts too short for large packages

Note: The web U/I never worked for kdebase-workspace, it was accepted via shell access by someone else.

Also kde4libs:

Timeout error
 Sorry, something just went wrong in Launchpad.
 We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience.
 Trying again in a couple of minutes might work.
 (Error ID: OOPS-1365C2235)

As Celso pointed out on bug 332529, the problem is still the query that simply asks for all the SPR's for a given source package name - for some reason it's taking around 4-5s and is executed 5 times. I'll try to find out why.

OK, in that specific example, we've got ~500 SPRs being instantiated just to get their id's for the in-clause of the next sql query. So I can do one really simple fix for the moment, that will not instantiate the SPRs but rather just get a list of ids (I'm guessing this is why the query *appears* to take so long - the object instantiation - but I'll verify that with cprov later).

It would still be good to find out why this query is being run 5 times... if it's worthwhile, I can continue looking into that as well.

So there will be a branch landing soon on edge that combines the two separate queries (the collection of all SPR ids, and then the builds for those SPRs) into one query. This should substantially reduce the time required for SPR.createBuild().

I didn't realise that Celso had already mentioned the cause of the multiple calls (one for each arch). I've taken a look, and it would also be possible for us to optionally pass the estimated build duration into SPR.createBuild() and calculating it during SPPH.createMissingBuilds() once for all architectures. We'll see if that's necessary.

This page seems to pretty regularly suffer regressions like this. If you
can figure out the root of it, I think it would be quite worthwhile.

The code behind the main page hasn't changed since the last optimisation. I know of two problems, but these are not regressions as such since we've not made changes:

 1. The page has trouble rendering if there are lots of packages with custom files attached
 2. When accepting packages that close bugs with a lot of subscribers, it will time out because the code is busy emailing lots of people.

The first one is easier to fix than the latter.

All I know is it breaks, bugs get file, it gets fixed, wait a few months
and it's broken again. While there may not be a regression in the code,
there is most definitely a regession in my ability to get work done.

Fixed in devel r9587 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/9587>

Thank you for the quick reaction on this. Does fix committed mean it's on
edge?

In a few minutes yes :). Assuming edge is updating as per-normal today, we should soon see > 9587 at the bottom of the edge page.

If you have other packages with lots of previous SPRs (ie. the kde4libs had ~500), try them out! If you still get an oops - re-open this bug and I'll look for further performance enhancements.

Thanks!

Does SPR equal Bug?

Sorry, SourcePackageReleases. And it looks as though edge has not yet updated too :/.