mysql-proxy-discuss team mailing list archive

[Adrienne Porter Felt <apf@xxxxxxxxxxxx>]

In case it's helpful to anyone, we'll post our code & numbers once we're
done trying to beat the bugs out of the code.  :D

On Tue, Sep 8, 2009 at 1:30 AM, Kay Röpke <Kay.Roepke@xxxxxxx> wrote:

> Hi!
>
> On Sep 7, 2009, at 7:49 PM, Adrienne Porter Felt wrote:
>
>  We seem to have fixed the problem.  When we use a Python profiler that
>> computes CPU time as opposed to wall time, we get the expected results (a
>> consistent slowdown for the proxy which decreases as the result set size
>> and/or complexity of the query increases).
>>
>
> I'm just a bit surprised that measuring wall clock consistently shows
> results going in the other direction,
> actually. The only explanation I can come up with is this running all on
> the same machines where the active
> threads exceeds the CPU/core count of said machine. Was this the case?
> Otherwise wall clock time should be
> higher, but exhibit the same general trend, no?
> But good that you could find and solve the problem!
>
>  The only remaining oddness is that increasing the number of connections
>> going through funnel still shows a speedup (that is, processing 1
>> query when 250 connections are open to the proxy and 1 connection is open
>> to
>> the backend is *faster* than processing 1 query when 10 connections are
>> open
>> to the proxy).
>>
>
>
> Maybe Nick has an explanation for that, I can't see an obvious reason why
> this should be true.
> It's worth writing a benchmark for that, though, and try to see if we can
> come up with profiling data that
> shows it (and then hopefully lets us understand it).
>
> Thanks for the valuable data!
>
>
> cheers,
> -k
> --
> Kay Roepke
> Software Engineer, MySQL Enterprise Tools
>
> Sun Microsystems GmbH    Sonnenallee 1, DE-85551 Kirchheim-Heimstetten
> Geschaeftsfuehrer:    Thomas Schroeder,  Wolfang Engels,  Wolf Frenkel
> Vorsitz d. Aufs.rat.: Martin Haering                    HRB MUC 161028
>
>