Peter said me that previous results https://www.percona.com/blog/2008/12/18/xtradb-benchmarks-15x-gain/ are too marketing, and we should show other results also.
Here is the run for CPU Bound,or it would be more correctly to say in-cache benchmark, because there is a lot of CPU remains idle. This run is exactly the same as Disk Bound but with innodb_buffer_pool_size=8G which is more than enough to fit all data in memory.
The XtraDB is showing very modest gain of about 2.5% in this case which can be attributed to measurement error too.
The story becomes more interesting if we look at CPU usage graph. As you can see they are very different for XtraDB and Innodb storage engines.
Innodb has generally higher CPU usage and more uniform while it has a huge dip in the middle. This happens because of checkpointing activity which can basically stall processing while dirty buffers are flushed. This is serious issue in real life application even though it does not significantly affects average throughput.
Honestly I’m not overly happy how XtraDB adaptive checkpointing performs in this case – we should see how to get it to be more uniform in this case.
So how does Average CPU usage looks ? You can see XtraDB delivers 2.5% better performance with 10% lower CPU usage…. which is more than the measurement error. So we think in workload which can utilize CPU more fully XtraDB will show more gains, though not 1.5x as for IO bound workload.
One may ask why CPU is not fully used in this case ? Honestly we did not investigate it further. One could be transaction commits (the run is with innodb_flush_log_at_trx_commit=1) which causes some overhead even though system has BBU installed. Other is simply properties of TPC-C benchmark which is rather lock intensive and may not be able to use all CPUs simply due to row level locking. Third is internal Innodb contention issues which also may serialize things not allowing full CPU usage.
BTW if somebody has 16 core box he can provide access to so we can do some benchmarks we would appreciate it.