On Thu, Sep 24, 2009 at 3:27 PM, Jay Pipes <jay.pi...@sun.com> wrote: > MARK CALLAGHAN wrote: >>
> > OK, no prob. > > We're always looking for more information on improving our performance > numbers, of course, but, like we found before with the Sun application > performance group, while the results show Drizzle has some performance > degradation over MySQL 5.1, nobody can tell us why that is the case, and > when we run OProfile or DTrace comparing MySQL and Drizzle, there is > virtually *zero* difference in the percentage of time spent on various > things...it's truly baffling, especially considering both profilers show us > having much fewer global contention points... :( > > In addition, as you know, we've been focusing on getting better scalability > on much higher concurrency levels than you are testing with. Sure, we are > trying to increase the overall performance, but the focus is on getting > scalability for 1000s of concurrent connections. Does Facebook really have > an average concurrency level of 16? > I was baffled by my current results for tcmalloc -- it doesn't help now. I think that a change in glibc versions explains that, but I am not using the most recent version of glibc yet that has event better malloc performance. I don't know what the average concurrency is. The variance is much more interesting and is very high. There are periods when concurrency is very high, much higher than 16. And periods when it is low. This bug -- http://bugs.mysql.com/bug.php?id=46459 -- was a big factor in some of the spikes. And when it is high the throughput degrades much more than needed because of excessive mutex contention. -- Mark Callaghan mdcal...@gmail.com _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : drizzle-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp