Timeout in product +rdf page

[Diogo Matsubara]

As seen in OOPS-1199EC113 the Product:+rdf page is timing out with a high statement count (> 1600)

see also bug 30793 for code duplication issues - the same issue probably (does?) turn up on Person:+rdf for teams and very active people.

[Curtis Hovey (sinzui)]

I'm lower this because this page is a low priority. This will be fixed when we work on the new project page. We will also examine what we want to do with the rdf pages.

[Curtis Hovey (sinzui)]

There are about 10 projects with more than 10 series. The series loops should exclude obsolete series, but that is not possible though the model object.

The main cause of timeouts is the expansion of the project owner team to all its members. The view/buildMemberData does a tremndous amount of work collecting member data. Can we only return admins, or provide links to each member's rdf?

Can we remove +rdf?

[Robert Collins (lifeless)]

How many sql queries are we issuing? Even for pretty large teams we
should be able to get a couple thousand entries back and rendering in
a couple of seconds.

[Curtis Hovey (sinzui)]

The most recent report (OOPS-1686C911) shows 1424 queries. The view is trying to gather all the gpg keys of the members.

    SQL time: 8753 ms
    Non-sql time: 10027 ms

The report states there is only one repeated query (true), but you can see that after we get what appears to all the gpgkeys, from the library, they are gotten again. The buildMemberData is building cached data, but the template that iterates over it does not gain any benefit.

    def buildMemberData(self):
...
        for key in sshkeyset.getByPeople(members):
            members_by_id[key.personID].addSSHKey(key)
        for key in gpgkeyset.getGPGKeysForPeople(members):
            members_by_id[key.ownerID].addGPGKey(key)
        for email in emailset.getPreferredEmailForPeople(members):
            members_by_id[email.person.id].setPreferredEmail(email)
        return members

[Curtis Hovey (sinzui)]

bug 30793 suggests that Lp link to the user, do not embed the data. Fixing that bug may address this one. If we do not want to switch to linking to users, then we should close the older bug. I favor switching to links because we cannot batch projects and teams with huge data. Our only option is to allow the rdf client to construct the full data it wants from the reference links in the base data.

There is also the option of removing the RDF link because it is very disappointing. Users want DOAP and FOAF,

[Robert Collins (lifeless)]

Linking would be fine, and in the rdf spirit.
DOAP and FOAF are rdf too; we can - and likely should - change our rdf
to be doap or foaf depending on the context.

[Robert Collins (lifeless)]

High as per zero oops policy.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r11630 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/11630>.