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?)
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.
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.)
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!
11 comments
[ 73.6 ms ] story [ 176 ms ] threaddimitrik.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.
Are any of these performance improvements portable to the forks?
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.
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!
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.