I'm back again (previous post in ths series is here
with some interesting finds related to some more testing of MySQL
Cluster testing (yes, I have promissed to test more things than this,
but I got so entangled with NDB that I just had to give it one more
shot). Looking at my benchmarking code, I realized I used the CLIENT_COMPRESS
flag when I connected to MySQL. This flag was there in the code where I connected to MySQL (using mysql_real-connect()
this is a C program after all) and it was probably just pasted in from
some other code somewhere. Not that this flag isnät known to me or
anything, but I had not tested the compressed or non-compress MySQL
client protocols much. I guess I at one time had assumed that
CLIENT_COMPRESS at best helps when sending large packets between the
client and the MySQL server, and above all, that for many small packets,
it wasn't terribly helpful, but also not terribly harmful. Turns out I
was wrong (yepp, that DOES happen).
Googling for CLIENT_COMPRESS, I didn't find much more than this either,
to be honest, if you have many small packets, it's not going to be very
helpful, but not very harmful either.
In this case though, it was the MySQL daemon maxing out the CPU that was
the issue, so maybe I should to to run without CLIENT_COMPRESS. As
stated above, Googling for this did not, at least not initially, provide
much help, but as the CPU was maxed out, and compression consumes CPU
power a lot, maybe we should avoid compression.
The result? 25 - 30 % more performance
, just like that! MySQL
Cluster with NDB is now managing some 46 k requests per second, as
compared to the previous 35 k! Not a bad improvement. All in all, using
MySQL Cluster using the MySQL API, as opposed to NDB, you probably want
to avoid using CLIENT_COMPRESS and you are likely to make many small SQL
statements with limited sizes of the result sets, and all data in
memory (well, not all if you use STORAGE DISK, but that has issues of
it's own), chances are that your performance bottleneck of the database
side of things, will be the CPU.
But don't get too excited, as I am now going to revisit this with InnoDB also! (Yes, that is mean)