February 8, 2010

Introducing tpce-like workload for MySQL

Posted by Vadim |

We have been using tpcc-mysql benchmark for long time, and there many results published in our blog, but that's just single workload. That's why we are looking into different benchmarks, and one
of them is TPCE. Yasufumi made some efforts to make TPCE working with MySQL, and we are making it available for public consideration.

You can download it from our Lauchpad Percona-tools project, it's
bzr branch lp:~percona-dev/perconatools/tpcemysql

Important DISCLAIMER:
Using this package you should agree with TPC-E License Agreement,
which in human words is:

  • You can't name results as "TPC Benchmark Results"
  • You can't compare results with results published on http://www.tpc.org/ and you can't pretend the results are compatible with published by TPC.

And we are not going to do anything from that, your primary goals is XtraDB/InnoDB performance research and/or compare with available Storage Engines for MySQL.

The workload in tpce is quite different from tpcc. Tpcc is write intensive, while tpce
is read oriented.
To give more details, there is stats for 10 seconds:

PLAIN TEXT
CODE:
  1. | Com_select                            | 46272       |
  2. | Com_update                            | 5214        |
  3. | Com_delete                            | 385         |
  4. | Com_insert                            | 3468        |
  5. | Com_commit                            | 5404        |

The result is quite chatty,

PLAIN TEXT
CODE:
  1. |    |     [MEE]    | [DM] |                         [CE]                          |
  2. sec. |    TR,    MF |   DM |   BV,    CP,    MW,    SD,    TL,    TO,    TS,    TU | MEEThreads, ReqQueue
  3.       (1st line: count, 2nd line: 90%ile response [msec.])
  4.  260 |   402,    39,     0,   195,   532,   749,   588,   342,   415,   816,    88 | 30, 0
  5.           20,    60,     0,    30,    20,    20,    20,    50,    20,   310,    60
  6.  
  7.  270 |   395,    40,     0,   201,   608,   842,   608,   358,   449,   833,    89 | 30, 0
  8.           30,    40,     0,    30,    20,    20,    20,    50,    20,   300,    50

but it allows you to see count of 11 different transactions per 10 secs and 90% response time.

and final result

PLAIN TEXT
CODE:
  1. [TradeResult(TR) transaction]
  2. Succeed: 150243
  3. Lated:   0
  4. Retried: 3
  5. Failed:  0
  6.  
  7. 41.7342 TpsE

where you can see count of successful TR (TradeResult) transactions, and
the summary result in TpsE (transactions per seconds).

Expect our results soon!

Posted by Vadim @ 10:30 am :: announce, benchmarks, mysql  
Print This Post Print This Post book mark Introducing tpce-like workload for MySQL in del.icio.usdel.icio.us :: submit Introducing tpce-like workload for MySQL to digg.comdigg  
Comment RSS  
Related posts: :Introducing percona-patches for 5.1::Quick look at Ubuntu 6.06::FlashCache: tpcc workload with FusionIO card as cache:
 

2 Comments »

  1. 1. Martin Dimitrov

    Thank you guys for publishing this work and for distributing your mysqltpce kit.

    The last couple of days I have been trying to get your kit to work with MySQL.
    I have followed the steps outlined in the provided README files – I have been able to create the database, load the data, create indexes etc.

    However, when I try to kick of a run using EGenSimpleTest, I get the following error:

    ./bin/EGenSimpleTest -c 2000 -a 2000 -d 200 -r 10 -t 300 -u 12
    EGen v1.9.0
    (for MySQL)
    (Prepared Statement)

    Using the following settings:

    Input files location: flat_in
    Database server: localhost
    Database name: tpce
    Database user: tpce
    Database password: tpce
    Configured customer count: 2000
    Active customer count: 2000
    Scale Factor: 500
    #Days of initial trades: 200
    Load unit size: 1000
    Test duration (sec): 300
    Ramp up duration (sec): 10
    # of Users: 12
    Waiting for Trade-Cleanup transaction finished…
    safe_mutex: Trying to lock unitialized mutex at my_thr_init.c, line 299
    safe_mutex: Trying to lock unitialized mutex at my_thr_init.c, line 299
    safe_mutex: Trying to lock unitialized mutex at my_thr_init.c, line 299
    Aborted

    Any insight will be highly appreciated.

    Thank you,
    Martin

    Comment :: August 19, 2010 @ 8:06 am

  2. 2. Martin Dimitrov

    I think I have moved past this problem.
    I think it was an issue with the mysqlclient_r library.
    I also think that it was related to a bug: http://bugs.mysql.com/bug.php?id=30274

    I recompiled mysql without debug, and I replaced the mysqlclient_r in /usr/local/lib with the newly compiled one.

    Thanks
    Martin

    Comment :: August 19, 2010 @ 2:38 pm

 

Subscribe without commenting

Trackbacks/Pingbacks