Blogs

Dedicated to Fernando Pedone and other modest and courageous researchers whose work made this possible.

Sysbench Synchrones Transatlantiques

Galera 0.7pre release was published, well actually 2 weeks ago already, and is now ready for downloads both in codership and launchpad sites:

• www.codership.com/downloads/galera
• https://launchpad.net/codership-mysql

Overview

This is an insert performance test implemented by running just inserts with mysqlslap against 1-3 node MySQL/Galera clusters. The results show how multi-master cluster can process more inserts than single native MySQL 5.1.38 server.

Test Platform

One of the pitch lines of the Drizzle project in their rewriting of MySQL code is to rely on standard libraries and make it a full blown C++ project, implying that there's no reason to hold back.

When we started Galera we explicitly decided to do it in C. We didn't have a confidence that libstdc++ was mature enough and expected to have all sorts of problems with it.

Bank restaurant that I have visited today and believe to be one of the largest restaurants (seat-wise) in Helsinki had elevated customer self-service to unparalleled (or rather super-paralleled) heights. The single mutex (cashiers) is locked only once and only to pay for food and grab fork and knife. The rest of IO (choosing and loading food) was totally asynchronous and evenly distributed between serving tables.

It been sometime since we benchmarked MySQL/Galera with sysbench, using it mostly for testing. Our recent visit to Percona Performance Conference showed that sysbench is probably most widely used tool for MySQL benchmarking in the community and besides it is the only benchmark I know that correctly measures response times. So I just gave it a shot with our 0.6 release.

So we've been there.

In my opinion the conference was a great success. Our presentation was not, but that's another story. Percona really showed what conferencing is about. Don't know about MySQL. It was behind the closed doors. Valiant guardians strictly watched that you didn't overhear a word of Sacred Knowledge. Hell, even to get to the Expo hall you had to pay $25 (that's right, you had to pay for watching advertisement) and surrender information about your private life, like your phone number and how you learned about the Expo.

This is the second part in in the series of posts about scaling Drupal stack. The first part can be found here.

GLB has been fixed to support unlimited connections and now I can benchmark Drupal stack cluster on large EC2 instances. What I'm looking for here mainly is how much Galera synchronization overhead affects performance here. With small instances everything was pretty much clear: single core hindered by Xen was an easy traget, and scalability was predictably linear. Large instance is dual core, and Xen interference is minimal, Galera synchronization and serialization effect must be more pronounced. How desperately bad is it?

Trend is an amazing piece of software that packs incredible amount of functionality into tiny amount of code and brief syntax. Trend is your universal live data plotter. It can work as oscilloscope and it can work as a regular strip chart plotter. It can get data from fifo or from standard input. It can read data as text or in binary form. It is almost completely configurable in runtime. In short: it is a pinnacle of software engineering, a crown of creation, an answer to all our needs and everything.

Drupal is a widely used content management system written in PHP that uses SQL server as a storage backend. Although Drupal can work with PostgreSQL, Apache/Drupal/MySQL stack is the usual production configuration.

A number of strategies were developed to scale Drupal performance through clustering, see excellent series of articles by John Quinn. Naturally all of them were capped by the SQL server component. Perhaps Galera is the "holy grail" of Drupal scaling-out?