Comments on: InnoDB benchmarks

By: Kaj Arnö’s blog » Blog Archive » MySQL 5.0.33 Community Server released

Wed, 10 Jan 2007 17:03:16 +0000

[...] Amongst the bug fixes, there is one that I want to highlight. It is listed as the innocent-looking bullet “InnoDB showed substandard performance with multiple queries running concurrently. (Bug#15815)“. This is a fix to an issue especially surfacing on multiple-core processors. You testing in such environments is much appreciated. As a reference, you may want to read the Bugs database entry bugs.mysql.com/15815 as well as two articles from Peter Zaitsev — one from a week ago, another from last September. [...]

By: peter

peter — Mon, 08 Jan 2007 08:52:41 +0000

SeBest,

Regarding benchmarks from Tweakers.net unfortunately the benchmark code itself is not available so the only thing we can say is there is something which runs faster on PostgreSQL than on MySQL. Without knowing what it is it is hard to say the reason for performance difference - might be it is “feature” related - some optimization is missing in MySQL.

To the question if you can increase features and performance at the same time - yes this is possible and this is the case with MySQL for some more complex cases. The simple cases as this benchmark uses there optimized down to the bones even with old MySQL versions so you only get slower because more fat new versions add.

I’m sure though MySQL can be brought back in terms of performance of simple queries if significant effort is applied to it - recent years focus of MySQL was more features and later bug fixes than performance.

By: sebest

sebest — Mon, 08 Jan 2007 00:15:36 +0000

About slower performance in 5.1 compared to 5.0 because of new feature.
This is strange that postgresql manage to have the same feature (or more) than mysql withoug being slower?!
This is what i understand from the tweakers.net benchmark in your previous blogpost.

By: UNIX-WORLD NEWS : InnoDB benchmarks

UNIX-WORLD NEWS : InnoDB benchmarks — Sun, 07 Jan 2007 22:08:59 +0000

[...] Peter Zaitsev wrote: [...]

By: Ilia Alshanetsky

Ilia Alshanetsky — Fri, 05 Jan 2007 23:16:27 +0000

Peter, I realize that increased code complexity and an ever increasing feature set usually does take a toll on performance. I am glad to hear that you are not discounting the slowdown and hopefully MySQL team will find the time for those difficult optimizations.

By: Log Buffer #26: a Carnival of the Vanities for DBAs · Steve Karam · The Oracle Alchemist

Fri, 05 Jan 2007 16:55:54 +0000

[...] Peter Zaitsev goes over some major enhancements for MySQL databases utilizing InnoDB including several bug fixes. His benchmark results from a variety of tests are also posted. [...]

By: peter

peter — Fri, 05 Jan 2007 16:21:26 +0000

Ilia,

Actually even 5.1 gains are uneven - in large portion of the cases it is slower than 5.0 (if you compare to 5.0.32)

Regarding reclaim slow down compared to 4.1 I would hope for that but I would not expect that. We profiled 5.0 compared to 4.1 and slowdowns were scattered across the code as it just gets larger and more complicated - this type of slowdown requires significant effort to fix and we shall see if resources will be allocated to it.

By: Ilia Alshanetsky

Ilia Alshanetsky — Fri, 05 Jan 2007 16:11:46 +0000

It is good to see an improvement in performance compared to previous 5.0 releases, however it seems that in most tests there is a slowdown compared to 4.1 versions. Any chance of this being rectified as well?

By: James Day

James Day — Thu, 04 Jan 2007 18:05:37 +0000

I know, but if you enjoy it, I’ll help your exploring.

By: peter

peter — Thu, 04 Jan 2007 09:31:00 +0000

James,

I know Adaptive mutex can be hotspot for certain workloads. I remember we disabled it a while back for this sort of workload - it becomes to scale better but performs worse.

Note we’re not paid to do MySQL performance profiling any more so there is limited free time we can spend on it