mysql-proxy-discuss team mailing list archive

[Kay Röpke <Kay.Roepke@xxxxxxx>]

Hi!

On Feb 17, 2009, at 6:57 PM, nick loeve wrote:

> I reset the funnel branch on launchpad, which is now using the changes
> from Jan's event threads branch.

Great to hear!

> ATM there is some memory corruption when backend connections are idle,
> a wait_timeout occurs, mysql kills the conneciton, and the connection
> is removed from the connection pool. Im currently debugging this,
> which seems to propogate as a segfault during libevent
> dispatching/loop-exiting in the event threads themselves.

Interesting. It sounds like a missing event_del to me.
Looking at the code in network_connection_pool_entry_free() the most  
obvious thing
would be to track the free_sock boolean to see what's going on.
I've just gone over the call sites for  
network_connection_pool_entry_free and all three
seem to correctly remove the event handler (one is non-obvious at  
first, at least to me at this hour).
The next best thing I can come up with is:
going from network_mysqld_con_idle_handle() to  
network_connection_pool_remove() to
network_connection_pool_entry_free() will attempt to remove the event  
handler.
Maybe the problem lies in there somehow.

> Pending the fix of that issue, we will do some more benchmarking, but
> some quick tests we did show that (at least in our funnel use case)
> there is alot of fine tuning to be had between no. of backend
> connections and no. of event threads. Should be interesting.

Certainly will be.
I'm very interested in doing benchmarks based on query execution time.
One I did recently simply used a SELECT SLEEP(?); query with increasing
microseconds as the delay. The other parameter I varied was concurrent  
clients.
I was only interested in q/s throughput for this benchmark, certainly  
adding resultset
sizes into the mix would be interesting, too, but I ran out of time.
(The reason to focus on query time was my earlier mentioning of the  
theory how it affects
proxy performance right now.)
Standing offer: If you have a benchmark to run I can arrange to  
execute it on some beefy
hardware with high concurrency across multiple machines and then post  
my results.

> > > Implementing a backlog mostly in a plugin is probably rather  
> > > painful in the
> > > long run,
> > > so I'd like to see this functionality to go into the core proper.
> >
> > Yes i agree. If you do not need a backlog, most of the implementation
> > can be fairly transparent IMHO.
>
> I changed a few things in backlog handling so that we can start moving
> it into the core. Im not sure of the best way to do it in a
> plugin-generic way, but it works for us so far.

We can surely figure it out as we limp along :)

> I fixed up a couple of the style things you mentioned also.


Cool. I'll take a look once I get over my jetlag and the, now  
traditional,
team meeting cold.

cheers,
-k
--
Kay Roepke
Software Engineer, MySQL Enterprise Tools

Sun Microsystems GmbH    Sonnenallee 1, DE-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfang Engels, Dr. Roland Boemer
Vorsitz d. Aufs.rat.: Martin Haering                    HRB MUC 161028