A few days ago MariaDB, MySQL and Percona all three released new versions of the 5.5 server. So I decided it’s time to run sysbench once more and compare the OLTP performance. The test candidates are:

  • MariaDB-5.5.24, using either XtraDB (default) or InnoDB
  • MySQL-5.5.25
  • Percona Server 5.5.24-26.0

For the benchmarks I used our trusty old pitbull machine which has 24 cpu cores, 24G of RAM and a nice RAID-0 composed of 3 SAS SSD.

The benchmark was sysbench-0.5 multi-table OLTP, using 8 tables with total 10G of data. InnoDB buffer pool was 16G, InnoDB log group capacity 4G (the maximum for MySQL). The mysqld process was constrained to 16 cores, sysbench to the other 8.

The only nonstandard tuning was for I/O scalability: innodb_io_capacity = 20000 and innodb_flush_neighbor_pages = none (for Percona Server and MariaDB/XtraDB). See my recent article on I/O tuning for an explanation.

The result for read-only OLTP is nicely balanced. This plot shows the median throughput:

also the response time is nicely flat (the plot shows the 99% quantile, means at most 1% of the requests was slower than that):

In fact the behavior shows nearly perfect scaling: up to 16 threads (= number of cpu cores for mysqld) the response time is constant. For higher concurrency we see a straight line in the double-logarithmic plot.

For read/write OLTP the picture looks quite similar, if we look at the transactions per second graph first:

The picture changes when we look at the response time (99% quantile again). The InnoDB based servers exhibit severe stalls caused by checkpointing as soon as we approach 16 client threads:

The XtraDB based servers handle the write load much better due to the better checkpointing algorithm.

Conclusion: if your workload is read-mostly OLTP, then it makes not much difference performancewise if you chose MariaDB, MySQL or Percona Server. So you can base your decision on other facts: costs, additional features (in MariaDB and Percona Server) or your internal know how.

The servers based on InnoDB (MySQL, MariaDB optionally) show slightly higher throughput, but suffer checkpointing stalls at high write load. MariaDB gives you the highest flexibility here, as you can chose between XtraDB and InnoDB.

Disclaimer: the raw benchmark results as well als scripts and config files used can be found in the public mariadb-benchmarks repository at Launchpad. There are also additional plots.

If you’re not on the announce mailing list (low traffic) or following us on Facebook, you’ve missed the announcement of MariaDB 5.5.24 (release notes, changelog). Highlights include:

  • Includes all changes up to MariaDB 5.3.7 and MySQL 5.5.24
  • We’re providing RPM packages for RHEL/CentOS 5 & 6, as well as a YUM repository
  • Ubuntu 12.04 has been released, so we have “Precise” packages
  • There are now BSD 9 and Mac OS X 10.5 binaries as well

Many new ways to get and use MariaDB, download MariaDB 5.5.24 and let us know how you’re liking it. 

We’re quite happy that we’ve released four major releases that are production ready (better known as generally available or GA in the MySQL world) in the last 26 months. That is just a little over two years, and a whole lot of features. In that same time, MySQL has seen one GA release (MySQL 5.5) and we’re all eagerly awaiting the upcoming MySQL 5.6.

You’ll note that we built MariaDB 5.1, 5.2, and 5.3 based on the MySQL 5.1 codebase. A significant number of features went into MariaDB 5.3 (our biggest GA release to date), with the biggest changes in the optimizer in over a decade. There were also many replication based changes included like the now famous group commit for the binary log. Our Knowledgebase has a summary of MariaDB 5.3 features.

Work on MariaDB 5.3 started long before MySQL 5.5 went GA. It was a huge task to move all these 5.3 features into MariaDB 5.5 and at the same time merge MariaDB 5.5 with MySQL 5.5. It caused a significant delay in us getting a release of MariaDB 5.5 out there as production ready software. By now it must be clear that we included all changes in MariaDB 5.5 from 5.3, 5.2, and 5.1. We spent the time developing new features and keeping it current against current versions of MySQL.

We released MariaDB 5.5 in April and we have always aimed for short release cycles where possible to keep up with rapidly changing distributions. With this in mind many have been thinking about the release cycle from now onwards.

What will the next release of MariaDB, which we are working on, be called? We want to release our new features in a GA version soon and not wait for MySQL 5.6 to reach GA quality. But if we release a GA version before MySQL 5.6 is GA, it will be very confusing to call our release 5.6. In addition, this time there are no free version numbers between 5.5 and 5.6 like there were between 5.1 and 5.5 when we could use 5.2 and 5.3.

We are thinking of calling it MariaDB 10.0. It will include stable GA-ready features from MySQL 5.6 (these will be backported), as well as encompass some of our plans for the next release. It will be based on the MySQL 5.5 codebase. Then we plan to release MariaDB 10.1, MariaDB 10.2 and so on.

What happens when MySQL 5.6 is GA-ready? We’ll release a MariaDB version 11.0. It will include all the features of MariaDB 10, and encompass the features from the MySQL 5.6 codebase (that weren’t already backported into MariaDB in a previous release).

Does this mean we are veering away from being a backward compatible branch to MySQL? Of course not. We will be feature complete. We’re just in the lull of time between MySQL releases, in a similar fashion to what we did for MariaDB 5.2 and MariaDB 5.3. Astute followers will note that there is no MySQL 5.2 and 5.3.

Essentially this is just a change in the numbering scheme. A change which allows us to release more often than MySQL does. You are invited to contribute to the conversation on the maria-discuss mailing list.