I wonder if I’ve missed something with configuring Percona server?

http://forum.percona.com/index.php/t/1623/

I know, but I expected the graph to be much more linear. From this graph it seems the throughput touches zero all the time, until some volume of data gets to the buffer pool.

Unfortunately latency report from tpcc-mysql benchmark is rather limited, we may fix that one day.

I have response time histograms for XtraDB and InnoDB-plugin

XtraDB:

1.New-Order

(time,sec) (count of transactions)
0.20, 1658223
0.40, 2095
0.60, 107
0.80, 32
1.00, 32

InnoDB-plugin:
1.New-Order

0.20, 945959
0.40, 6285
0.60, 319
0.80, 56
1.00, 23

It’s expected that increased throughput affects response time, from queue theory,
the response time grow exponentially on increasing throughput.

First part on RAID10 graph is just buffer_pool is warming up. I show results
from 0 point of time (from restart of mysqld), and for RAID10 HDD it takes much longer to fill buffer_pool.

did you measure query latency? Throughput benchmarks look great, but the latency is crucial for web applications. We’re using XtraDB 7 with 40GB buffer pool, RAID10 with HDDs and when the write throughput goes up, we see read query latency dips in about 500-1500ms.

What about the XtraDB RAID10 graph – the first part of the graph looks scary. Is there any explanation for that.

Thank you for your great job and for publishing these benchmarks

I just made another run with the adaptive hash indexes disabled, but it does not help, and
final result is worse.

Actually in most cases, despite there is contention on adaptive hash index,
disabling it does not help, as in this case, InnoDB has to do much more work on index pages scan.

Thank you, I fixed that.

Usually I used deadline (for RAID), but
in this case there is no scheduler settings for software RAID nor for FusionIO cards.