launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Tue, Aug 3, 2010 at 10:02 PM, Robert Collins
<robert.collins@xxxxxxxxxxxxx> wrote:
> On Tue, Aug 3, 2010 at 12:49 PM, Robert Collins
> <robert.collins@xxxxxxxxxxxxx> wrote:
>> Just a reminder - I'm spending today, all day, just poking at
>> performance; I'm 100% interruptible for performance related questions
>> / tasks / todos & gotchas.
>>
>> And if anyone wants to join in, please do so!
>>
>> Right now, I'm about to finish up a small backlog of emails, then look
>> into why https://api.staging.launchpad.net/beta/~ubuntu-dev/participants
>> takes 8 seconds.
>
> So, I'm heading off to sleep, and I haven't got a mergable branch yet,
> though I do have some small test cleanups.

I've landed the basic cleanups, and just finished putting together a
followup branch that includes all the support stuff I was missing to
write a simple assertion about the sql behaviour:
https://code.edge.launchpad.net/~lifeless/launchpad/registry/+merge/31830
contains this merge including an example test using the new helper,
and the test output it creates (which things like tribunal will show
as separate attachments).

assertStatementCount wasn't suitable for two reasons: its coupled to
'this thread' rather than 'this web request' - which while identical
*today* isn't necessarily true long term. Secondly, its an exact match
rather than a boundary checker.

So this puts me back at looking into the sql count for /participation:

> So back to /participation, when we looked at this, the OOPS suggests
> mostly nonsql time, but had 400 SQL queries, and the python trace
> shows lots - lots! - of time in storm and in getattr's.

> So what apparently happens here (this is where Tim helped out :)) is
> that lazr.restful is introspecting *every declared attribute*; so we
> have 'allmembers' which is a person property that does a (fairly
> cheap) query, and then that cheap query is expanded item by item,
> property-by-property. (Oh, and hint for finding the right method -
> grep for 'exported_as.*URL_SUFFIX' - e.g. exported_as.*participation -
> in the interfaces files.

For 2 people in one team, this API takes 31 separate round trips to
the DB, and 8 more per person added - its pretty easy to see why it
scales up to thousands of round trips pretty quickly.

Now, I'd like to ask for some advice. There seem to be three ways of
fixing this:
 - (somehow - I don't know the magic) tell lazr.restful to skip some
attributes (e.g. karma, coc_signed etc) for representations.
https://bugs.edge.launchpad.net/launchpad-foundations/+bug/251284 -
makes note of things being removed from representations, but I don't
know whats involved in doing that (yet). Or I may be misunderstanding
and actually its an all-or-nothing solution. Leonard, if you could
comment here (or there) and help enlighten me, I'd really love that :)
 - we can build a cached decorator like code does - need to check if
any users of this will be broken, and how does it interact with
mutation operations
 - we can fix the main code path to grab all the stuff needed (like
the cached decorator option, but in the model) - this may help
+participation too, which seems to have a similar, high, query count.

is there any advice on whats likely to work best - what has been
working well for us so far?

-Rob