October 24, 2014

MySQL versions shootout

As part of work on “High Performance MySQL, 3rd edition”, Baron asked me to compare different MySQL version in some simple benchmark, but on decent hardware.

So why not.

I took our Cisco UCS C250 and ran simple sysbench oltp read-write all data fits into memory workload.

Versions in question:

  • MySQL 4.1
  • MySQL 5.0
  • MySQL 5.1 (with built-in InnoDB)
  • MySQL 5.1 with InnoDB-plugin
  • MySQL 5.5
  • MySQL 5.6

All versions are vanilla MySQL, not Percona Server.

The results are there:

There is nothing unexpected, staring with InnoDB-plugin, MySQL scale much better on multi-cores, there is gain up to 1.7x in throughput.

What is interesting there, let’s take look on single thread results:

You can see that each new version is slower in single thread than previous.
It is actually easily explainable: each new version adds more features, which give more overhead.
Profiling MySQL 5.0 vs MySQL 4.1 couple years ago, I have seen biggest performance hit comes
from query parser. In MySQL 5.0 grammar became much bigger because of storage procedures and triggers.

And raw results, in tps (more is better)

threadsMySQL 4.1MySQL 5.0MySQL 5.1MySQL 5.1+InnoDB-pluginMySQL 5.5MySQL 5.6.2
1685.52639.73596.01593.51531.07525.80
21306.501221.401139.601139.201076.591018.64
42274.832167.922031.802042.511937.641830.80
83879.113746.293606.023681.363522.653320.10
164373.824527.044392.816130.705881.405572.50
324591.424864.464698.397762.327548.937138.54
644688.415078.024910.217535.657269.476994.04

Scripts and results are also on our Launchpad Benchmark project



About Vadim Tkachenko

Vadim leads Percona's development group, which produces Percona Clould Tools, the Percona Server, Percona XraDB Cluster and Percona XtraBackup. He is an expert in solid-state storage, and has helped many hardware and software providers succeed in the MySQL market.

Comments

  1. nate says:

    Could you post the mysql configurations you used? Also may be helpful to call out that the server in question has only 12 cpu cores/24 threads, at first I was confused why performance went down from 32-64 thinking it was just a mysql scaling thing but may have more to do with the underlying hardware not being able to keep up.

  2. Andy says:

    Hi Vadim,

    Can you also benchmark Percona, MariaDB, Drizzle? Those 3 are often seem as the improved-versions of MySQL. It’d be nice to see how they stack up against stock MySQL and each other.

  3. Andy says:

    It’s surprising to see 5.1+plugin actually performs better than 5.5, 5.6 in your benchmark, especially in high concurrency.

    I thought 5.5 & 5.6 contain improvements especially for the high concurrency use case, so I expected them to be faster than 5.1+plugin.

    Any ideas why they are actually slower?

  4. nate,

    I posted config file to Launchpad.

  5. Andy,

    MySQL 5.5 and 5.6 have good improvements for 256+ threads, I did not test to that amount of threads
    in this benchmark.
    In smaller threads, I am not sure why it is slower, probably just regular overhead of new features.

  6. Vadim,

    I wonder how MySQL 4.0 behaved… especially in single thread. I remember number of people saw regressions going to MySQL 4.1 and there might be a lot of reasons (like complex character set supports) for slowdown for 4.0->4.1

    Other question is configuration – I see configuration file is large with a lot of stuff commented out. Do I understand correctly and you used same configuration for all versions, not enabling any special settings, such as multiple buffer pools on MySQL 5.5 and above ?

    Also I’m not sure the config file posted (my.cnf) is correct at all. It contains:

    innodb_log_file_size = 4000M
    #innodb_log_file_size = 1024M
    #innodb_log_file_size = 256M
    innodb_log_files_in_group = 2

    As you can see it is 4000M log file with 2 log file in group which is enabled, which will not work with MySQL before MySQL 5.6

Speak Your Mind

*