On Mon, Mar 16, 2009 at 1:24 PM, John David Duncan <[email protected]> wrote: > > The first pool-of-threads implementation for MySQL 5.0 (which is > Solaris-only and is quite different from the 6.0 libevent code) is in heavy > production use on about 20 servers, using the memory engine, with each > server handling 15,000+ simultaneous client connections, and around 20,000 > queries/sec. It does *not* perform measurably worse than the standard 5.0 > connection handler in any way. Igor Chernyshev, who now works at Google, > knows a lot about this code, and Chris Kasten has given a presentation on it > at the MySQL Conference. > > But, when you use this stuff with InnoDB, one problem is that InnoDB has a > built-in "pool of threads" (a limit on the number of threads allowed into > the InnoDB kernel at any one time) that becomes completely redundant -- so > the first thing you have to do to get decent performance is set > innodb_thread_concurrency = 0 to disable it. > > Also, there are timeout-based problems, and if all 6 (or 8, or whatever) > running threads stall, then the whole server is hung. Folks who work at Sun > can look at MySQL support issue #25334 and see some problems that might also > pop up in conceivable libevent-based implementations... > > JD > >
JD, Am I correct in summarizing this by stating that MySQL has a fast version of this in code I can't review and problems with it are described in a problem report I cannot read? This is my guess at what some of the architectural issues are with this feature: http://mysqlha.blogspot.com/2009/01/no-new-global-mutexes-and-how-to-make.html -- 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
