launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 7 September 2010 07:39, Robert Collins <robert.collins@xxxxxxxxxxxxx> wrote:
> On Tue, Sep 7, 2010 at 8:53 AM, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:
>>>
>>> Didn't realize that. Yes, we can get the output to the client. It is
>>> in a particularly unreadable format so we would need to render it like
>>> EXPLAIN does, and big so we certainly won't want to do this for all
>>> requests, but it looks doable. I also notice we can inform the client
>>> when it has waited for a lock longer than 1 second, which would be
>>> cool to log.
>
> That would be lovely.
>
>> Yay.
>>
>> Even a crude rendering is so much better than a possibly multi-day
>> delay for people to try to recreate why their query is slow.   I think
>> if we just enable this on the server side we can have the client just
>> turn this on only when ++dblog++ is on which should reduce the normal
>> overhead (testing obviously needed).
>>
>> Can you try adding it?
>
> This will almost certainly increase request and server overhead;
> perhaps we should only do this when:
>  - ++oops++ is present
>  - the user is an LP developer or sysadmin

I had in mind to turn it on from a separate url decorator, ++dblog++
(better name welcome) so that you can have it on even for a successful
execution, and so it won't change the behaviour of a regular oops by
for example skewing the timing.  I don't think it would need to be
limited to lp devs or sysadmins unless you think people will try to
DoS us by sending many  requests with that decorator: if they want to
do that kind of thing there are plenty of existing expensive URLs they
could hit.  But at this point it probably just needs someone to do
it...

> Either way, its not a trivial change to make to the system by virtue
> of being so deep in the plumbing, I'd really like us to track this via
> a bug and be sure to QA it carefully on staging.

+1

-- 
Martin