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

Reply via email to