I have updated my blog with a throughput charts – for folks who want to look at the stability of the same SchoonerSQL run:

http://darpanetwork.blogspot.com/2012/01/schoonersql-throughput-with-perconas.html

Yes, I will add more details after understanding the output some more with Vadim’s help.

Let’s see if I can move you along this process:
Doubt -> Verify -> Trust.

Darpan

So I can only agree that all details (configurations, data, queries/scripts) should be available. As long as this is not the case any postulate is as good as another.

No question Percona did a thorough job writing the white-paper for Clustrix. Having done performance benchmarking, I can surely understand the time it would have taken to execute all those runs, validating data (rerunning benchmarks if necessary) and then plotting all the results.

I think its easy to get carried away with the title of Pavan’s blog. 9 Clustrix nodes with 48GB DRAM each = 432GB, incidentally the size of the 5000 warehouse tpcc-mysql database. The core question is if the scalability of Clustrix efficient? I picked one data-point to pursue that question. To make that point, I blogged about it here: http://darpanetwork.blogspot.com/2012/01/how-scalable-is-clustrix-scalability.html
and then put in tpcc-mysql details:
http://darpanetwork.blogspot.com/2012/01/schoonersql-throughput-with-perconas.html

BTW I did want to ensure stable environment and results, so I did have a 4 hour long run.

If you provide a cheat-sheet, in addition to the CPU util chart already posted, I will add throughput and latency charts for the run.

So let me ask this: lets say you validated my results. Will you ask the question: for what workloads and price/performance will a Clustrix or similar building-block (with a fraction of throughput capability) be better suited for?

If someone pays me, I will love to do 128 runs for comparison – any takers? ;-)

We measured MySQL v5.5 and shared results at the April 2011 MySQL User Conference comparing async, semi-sync and Schooner-sync replication between two identical nodes in Master/Slave configuration. For MySQL 5.5 async and semi-sync runs, we ensured slave lag ~< 1 sec by tweaking DBT2 think-time. If this were not done, Slave can get hours behind (slave lag) for every hour of benchmark run.

I believe you are referring to the results in the slides: http://www.slideshare.net/darpandinker/performance-comparisons-and-trade-offs-for-various-my-sql-replication-schemes-presentation

Notice the choppy throughput with async Master and Slave vs more stable throughput with semi-sync for MySQL 5.5. I was hoping you have similar runs and can explain it if you see the same.

If you think MySQL 5.5 async vs semi-sync data doesn't look right, we can run it again for you and share the results. Given the same benchmark conditions, I would still expect to see 4X throughput gains with SchoonerSQL in reruns.