EC2

So, when I posted new benchmarks about intercontinental synchronous replication performance, I kinda was not sure if that 6000 km disaster recovery scenario was not blown out of proportions.

So, the other day I posted the performance benchmarks for the multi-master MariaDB/Galera cluster. Spectacular performance. But some of you may justifiably say:

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

Sysbench Synchrones Transatlantiques

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.

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?

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?

As you might already know, DBT2 is an OLTP benchmark similar (but not equivalent) to venerable TPC-C. A couple of months ago I tried it with Galera on Amazon EC2 to see how Galera performed in a non-LAN environment. It did quite well, especially in high availability regard. Since then Galera saw a whole lot of bugfixes and improvements, so the time has come to try it once again. This time it will be 'large' AWS instances, almost 8 gigs of RAM and two CPU cores, you know, Big Iron or something.

How would Galera perform in this setup?

This is the first in the series of articles about Galera on Amazon EC2, here's the follow up.
Galera benchmarks on Amazon EC2 have been long overdue. There are at least 3 reasons why EC2 performance is so important to Galera project: