11 comments

[ 73.6 ms ] story [ 176 ms ] thread
500K - as in half a million, you missed the K in there ;-)

dimitrik.free.fr is a great source of info for mysql performance with careful benchmarks to prove everything...

Bothers me that 5.6 is just getting settled in, yet 5.7 looks even more promising but will take a year or more for GA

They also need to look into either a multi-segmented or multi-threaded query cache.

Oops! Thanks for mentioning that omission, I've updated the title.
Nice that it's compared to the other MySQL-like database engines, including MariaDB.

Are any of these performance improvements portable to the forks?

I was laughing at you until I realized that it was 500000 queries/sec.
If you look at the config files at the end:

    innodb_checksums=0
    innodb_doublewrite=0
    innodb_support_xa=0
Ok, so this is a benchmark with no regards for data safety that you'd like on a live system. No two-phase commit, no protection from partial page writes. Great in theory, but it should be really pointed out in the article (or did I just miss it?)
Next they will show you how to increase MS SQL performance with "NOLOCK".
It's admittedly hard to follow the writing style, but it's mentioned many times that these are read only queries.

I agree it's a little misleading, but at the same time if you're really in a readonly DW type environment you'd be crazy not to have all of the settings enabled to push throughput to the max.

Duh... yeah, my bad. I looked so much for the option details that I missed the whole thing was R/O. Thanks for pointing this out.
Wow, that is very impressive. I look forward to seeing 5.7 hit GA (although as ck2 points out, that's probably some time from now).

I'd like to see how 5.7 affects our framework benchmarks [1] since the highest rate we observe in our project with 5.5 is ~145,000 per second by cpoll-cppsp when running 20 read queries per request (7,252 rps). Our project is obviously not a database benchmark—it's a web framework benchmark—but nevertheless I am interested in whether a significantly quicker database platform would yield notably higher performance on that test type.

(Many other variables differ of course. The queries we are running are presumably much simpler and our hardware is much smaller.)

[1] http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...

Edit: Apparently someone has flagged this article submission and it's now on page two. I don't get the motivation. Yes, the content may be a little difficult to follow, but it's fascinating. Oh well!

I think what the benchmark is proving is that 5.7 uses all the cpu cores where 5.6 in all variants and predecessors does not.

5.7 is not much faster than 5.6 with less than 16 (HT) cores.

But by the time 5.7 ships GA, we'll need it as cores will be far more plentiful.