I think that server consolidation and CMT may be a good match as long as there are good management tools.

“How are we expected to manage this? Running ‘/etc/init.d/mysql start’ separately for each instance doesn’t scale when there are tens or hundreds of instances on a box. What is the management tool?”

We’ll be publishing the Tungsten Manager in open source later this week–it uses group communications to do broadcast commands to start/stop/restart network services. With large clusters group communications move from the realm of academic curiosity to a very useful tool. Stay tuned…

Cheers, Robert

(From now on I won’t call you MrBenchmark). Yes, we know, actively writing a scalable engine. But I have some questions for you.

Do you understand what Mark’s comments about linear scale-down mean? Do you understand the implications of that? Why don’t you translate Mark’s comments, repost them in your own words, and let’s see what you think it means.

What is your job, exactly? Is it to generate conversations? I mean, on the one hand you’re putting out this paper, and on the other you’re saying it’s not even meant to be a technical reference, it’s just to start conversations. Are you Sun’s version of SciGen, then? People are still having conversations about SciGen, years later. Success! Are you MrBenchmark or MrConversation?

Your comments put you and your paper in a new light, which I think is how most people have viewed things all along. Do you think what people are saying in private email conversations about you and your work is a success?

Thanks for your great comments. The intent of my initial blog post as well as the (marketing – YES !) BluePrint is to generate a conversation about MysQL with CMT servers. As far as I am concerned, this is a success. MySQL on CMT is not a Reference Architecture but an available option. Be sure that SUN is very actively writing code to produce a highly scalable engine.
So, I’d like to propose the following correction for Robert’s wall: “Writing SCALABLE code is harder than writing marketing material”.

I don’t think that article does CMT justice. First, for the single system tests the results show linear scale-down (rather than scale-up) for throughput. The test determines the max per-client throughput at high concurrency and uses that to rate limit clients at low concurrency. The same technique can be used to show linear scale-up for just about any server software.

Second, it shows great throughput on a workload when you shard a database. That is not a good reason to shard a database. The focus of the article should have been on server consolidation for which CMT servers are well suited.

Finally, if you are pitching big CMT boxes for consolidation, then this isn’t a solution yet. How are we expected to manage this? Running ‘/etc/init.d/mysql start’ separately for each instance doesn’t scale when there are tens or hundreds of instances on a box. What is the management tool? The tool is even more critical when you move to cloud deployments with many big CMT boxes and even more database instances to manage.

It’s also not too late to edit the blueprint and amend the comments about people whom, the authors apparently believe, have been stuck in patterns that their limited intelligence doesn’t let them escape. Those phrases tend to make the whole paper sound arrogant and chest-thumping.

But it’s just a PDF that can be edited and re-uploaded, if you see what I mean. It might serve Sun better that way.

MrBenchmark’s comments in the blogosphere are very unlikely to be so easily redacted, though

Very good to hear. Your approach makes sense and indeed there is variety of the architectures and hardware solutions which excel in different cases. You have described this as a niche solution and It would be very nice if blueprint would also do that – outlining exact assumptions where such approach makes sense. Such important sections are omitted way to often.