As we have mentioned several times you probably know we are planning to migrate our development over to the innodb-plugin and start following the path of the storage engine.  That’s all well and good but what are the warts and bugs and things we are trying to fix?  Ahhh yes the seedy underbelly of Waffle Grid. The reason why we call it experimental.

Big on my list is going to be ensuring data integrity.  Currently you can manually ( or via some weird network corruption ) overwrite a good innodb page with an invalid one, the result? Well lets check it out:

I have just uploaded a technology preview release of Waffle Grid code named “Butter”.  Yes Butter is good on Waffles.

This release is a preview release, experimental, and should probably not be used in production unless you are brave…  I am including the full source for this release.  This includes patched memcached, libmemcached, and MySQL 5.1.30.  I bundled it this way to try and get folks to try it out and let us know what they think.  This is probably going to be the only time we package the full MySQL source as we are now working with the innodb-plugin.  You can still grab this as a patch off of launchpad.

What’s in this release?  Well this is our first “release”  but some of the notable items since the last …

A quick one here, we often talk about effectively utilizing memory to get the most of your MySQL Server.  I wanted to remind folks to not forget about allocating memory to a tmpfs for the tmpdir.  Certainly this is not going to help everyone, but those who create lots of temporary table will find the performance boost most welcome. In fact in some cases you maybe better off allocating a little extra memory to a tmpfs then you would be the innodb buffer pool, but like everything it depends on your workload and environment.

What is tmpfs?  In a nutshell a filesystem ontop of a ramdisk  used for temporay file access.  Read the wiki page for more.   Sounds like a great thing for /tmp right? By the way It really urks me that most people leave /tmp as part of the root filesystem ….  shameful, read my common mistakes post for more complaining …

I harped on this earlier this month. The network is an often over looked, but vital component of every application. I have been in many shops content with running 100Mb/s between the application and database simply because they are no where near maxing out the available network bandwidth between the two servers. What they are forgetting is there is a big latency difference between 10Mb,100Mb, & 1000mb. Speaking from my testing on Waffle Grid we see that under load 100mb connection routinely has network latency in the 3000-4000 microsecond range, while running under load in 1gbe tests we routinely run at around 1100 microseconds. By the way the same test using a Dolphin interconnect card finishes with an average latency of less then 300 microseconds. These tests average less then 5Mb/s being pushed over the network, which from a network perspective would not even hit half the available …

Let’s grab your attention with a shameless marketing ploy:  How would you like up to a 14X performance boost in your Mysql database performance? Now your hooked who wouldn’t want a 14x boost?  Well we got that using Dolphin interconnects and Waffle Grid! Read on!

As you know over the last few weeks the good folks over at Dolphin Interconnect Solutions have lent me use of a couple of servers with their interconnects installed ( They also sent me a couple of cards to test with, but I ended up not being able to secure the hardware to put these through their paces at my home office ) .  I ran into several challenges in the testing, and we also found out a lot about Waffle Grid and where we have some open bugs ( its good to test Waffle at the fringe of performance and see what breaks).

The oddest thing I ran into here was the way using the Dolphin cards …

Because I was asked….What should I set my my.cnf parameters to? What are good default values? How much memory should I allocate to the db if I have X amount of ram? What is a good starting point for the mysql config files?

You’re not really Googling for a my.cnf to use are you? You probably are, Shame on you!  The best thing to do is to test before you make changes, and find the best configuration for your application.  But your not going to are you? oh well I might as well accommodate you. I make no claims these will work for everyone. In fact if you hire me later on I may look at you funny after I analyze your system, and may call you funny names behind your back for using the wrong settings.  Because there are a lot of people out their who are only database folks 5 minutes at a time (that’s what these posts are about), they are probably going to stick the my-huge.cnf and go with that anyways.  So why not throw …

An often overlooked and way underrated component to any site is the collection and reporting of solid historical performance metrics.   Don’t get me wrong, everyone collects some sort of web page stats, has access to mysql status variables, and uses top to check cpu and process stats ( what else does anyone need right?).    But the metrics I am talking about are not your simple # of pages,# of users, apache log metrics that everyone has in their web server, nor are they point in time cpu stats, or cumulative row accessed counters.  No, we  are talking about true performance stats, gathered over a long period of time.  These stats can be used for troubleshooting, trending, and make great art and conversation pieces ( have seen my one of a kind CPU graph).

Think of it this way,  someone complains your site is slow.  They say when they hit the first page it just seems sluggish.  What does …