My analysis was based on benchmarks and described in a few blog posts. This is interesting for a few reasons.
1) replication is single-threaded at least for a few more years. Eventually we will all have the Kristian-inspired idea of getting parallel replication apply even when there is only one database shard and that helps some. But there are always some workloads that really are single threaded on the master and during replication apply.
2) fast storage means that IO-bound workloads might be able to get 100,000+ IOPs on a commodity server. So even when IO-bound we need much higher throughput in the past
3) At least with public-facing information Oracle doesn't write about this topic. Their performance focus is high concurrency.
4) RAM per host is much larger so more workloads are not IO bound and expect high throughput

I don't think a complex workload is needed to show the problem. sysbench and dbt might be sufficient. linkbench should also be useful to MariaDB.

http://mysqlha.blogspot.com/2013/09/mysql-41-forever.html
http://mysqlha.blogspot.com/2013/09/single-threaded-connect-performance.html
http://mysqlha.blogspot.com/2013/09/mysql-572-single-threaded-performance.html
http://mysqlha.blogspot.com/2013/05/mysql-56-single-threaded-performance.html
http://mysqlha.blogspot.com/2013/05/mysql-56-versus-40-for-read-only.html
http://mysqlha.blogspot.com/2013/04/mysql-56-single-thread-update-only.html
http://mysqlha.blogspot.com/2013/03/mysql-56-single-threaded-read-only.html


On Mon, Jan 20, 2014 at 8:18 AM, Sergey Vojtovich <svoj@mariadb.org> wrote:
Hi Mark,

we identified a few single-thread performance issues during the Barcelona
meeting. Monty should have them fixed in his private tree. Fixes are quite
generic and should improve performance almost in all cases. An exception is
bottlenecks specific to certain use cases.

Could you send me any relevant information my way if you have it around?

Thanks,
Sergey

On Mon, Jan 20, 2014 at 08:00:45AM -0800, MARK CALLAGHAN wrote:
> Are there other goals for single-thread performance regressions? There are
> many that have nothing to do with replication code  although almost every
> single-threaded replication hurts replication.
>
>
> On Mon, Jan 20, 2014 at 2:54 AM, Axel Schwenke <axel@askmonty.org> wrote:
>
> > Hi,
> >
> > for those of you who didn't attend the Barcelona meeting last week, here
> > are
> > the plans for next steps in benchmarking:
> >
> > 1. top priority is automatic running of DBT3 for each new release of
> > MariaDB-10.0 and MySQL-5.6. Probably also for MariaDB-5.5. I'll send out
> > another mail to pinpoint DBT3 conditions (i.e. which table statistics to
> > use
> > etc.)
> >
> > 2. multithreaded replication slave is now in a condition that it can and
> > should be benchmarked
> >
> > 3. the problem pointed out by Yoshinori in
> >
> > http://yoshinorimatsunobu.blogspot.de/2013/12/single-thread-performance-regression-in.html
> > must be checked for MariaDB. Monty announced that he will commit a patch
> > this week that should help with that problem.
> >
> > 4. for the NUMA scalability problem, Kristian will try to find the
> > definitive reason with profiling tools. Besides that ad-hoc testing of new
> > patches from Svoj continues as before.
> >
> > 5. Galera benchmarking will be done by the Galera team for now.
> >
> >
> > XL
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~maria-developers
> > Post to     : maria-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~maria-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>
>
> --
> Mark Callaghan
> mdcallag@gmail.com

> _______________________________________________
> Mailing list: https://launchpad.net/~maria-developers
> Post to     : maria-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~maria-developers
> More help   : https://help.launchpad.net/ListHelp




--
Mark Callaghan
mdcallag@gmail.com