On Mon, Mar 16, 2009 at 12:38 PM, Jay Pipes <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > MARK CALLAGHAN wrote: >> On Mon, Mar 16, 2009 at 10:57 AM, Brian Aker <[email protected]> wrote: >>> FYI (This was an internal reply I made, but I believe anyone on the list >>> would find it interesting). >>> >>> Begin forwarded message: >>> >>>> Hi! >>>> >>>> On Mar 16, 2009, at 1:29 AM, Jay Pipes wrote: >>>> >>>>> Frankly, libevent is being used entirely incorrectly in pool_of_threads >>>>> plugin... >>>> Yep! >>>> >>>> Though even in its current state if you are doing just primary key lookups >>>> it will outperform the threaded handler (spin up slap on the key test). The >>>> problem is that you need to be able to catch a IO event on a non-blocking >>>> port to make better use of it. >> >> Jay, >> >> Can you give more details on the case where pool-of-threads makes >> anything faster? I have no problem making sysbench throughput 2X >> slower when pool-of-threads is used with MySQL 6.0. >> http://bugs.mysql.com/bug.php?id=42288 > > I didn't say that; krow did. I've never seen pool-of-threads perform > better than the multi-thread scheduler for anything and most times it > can't even make it past 16 threads in benchmarks. > > I hacked up a new scheduler yesterday which uses a scoreboard system and > am waiting for krow to merge my latest changes into trunk so I can > benchmark it. I'll keep the list updated on that. > >> Did drizzle make significant changes to this when porting it? > > No. it's almost identical to 6.0. > > Cheers, > Jay
That is good for me then. We backported it as is from 6.0 to 5.0.37. We have the same problems to solve. > >>>> Though... the problem still exists that a port that continues to "block" >>>> will hold up any other transactions that will conflict. In the current >>>> state >>>> this is a bit worse then what it should be because we are not releasing to >>>> another sessions well enough (aka... we need to do this on IO event). Even >>>> fixing that though... this type of scheduler will only really work for >>>> cases >>>> were you have short transactions, or a large amount of read IO. In the end, >>>> libevent just gives us a scheduler for one particular type of IO. >>>> >>>> Long term? Some sort of scheduler that can grow or shrink... or possibly >>>> something where we can really do priority in the queries (aka... connect >>>> into the optimizer and use estimated cost). >>>> >>>> Cheers, >>>> -Brian >>> -- >>> _______________________________________________________ >>> Brian "Krow" Aker, brian at tangent.org >>> Seattle, Washington >>> http://krow.net/ <-- Me >>> http://tangent.org/ <-- Software >>> _______________________________________________________ >>> You can't grep a dead tree. >>> >>> >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~drizzle-discuss >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~drizzle-discuss >>> More help : https://help.launchpad.net/ListHelp >>> >> >> >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkm+qp0ACgkQ2upbWsB4UtHStgCfbv5IznOltpwuwPS5p2IlbxwS > Qh8An3aGPcarFR5uVZ5y26oervY8YF90 > =HPbK > -----END PGP SIGNATURE----- > -- Mark Callaghan [email protected] _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
