percona-lab / tpcc-mysql

1. Build binaries

   • cd src ; make ( you should have mysql_config available in $PATH)

2. Load data

   • create database mysqladmin create tpcc1000
   • create tables mysql tpcc1000 < create_table.sql
   • create indexes and FK ( this step can be done after loading data) mysql tpcc1000 < add_fkey_idx.sql
   • populate data
     • simple step tpcc_load -h127.0.0.1 -d tpcc1000 -u root -p "" -w 1000 |hostname:port| |dbname| |user| |password| |WAREHOUSES| ref. tpcc_load --help for all options
     • load data in parallel check load.sh script

3. Start benchmark

   • ./tpcc_start -h127.0.0.1 -P3306 -dtpcc1000 -uroot -w1000 -c32 -r10 -l10800
   • |hostname| |port| |dbname| |user| |WAREHOUSES| |CONNECTIONS| |WARMUP TIME| |BENCHMARK TIME|
   • ref. tpcc_start --help for all options

Output

With the defined interval (-i option), the tool will produce the following output:

  10, trx: 12920, 95%: 9.483, 99%: 18.738, max_rt: 213.169, 12919|98.778, 1292|101.096, 1293|443.955, 1293|670.842
  20, trx: 12666, 95%: 7.074, 99%: 15.578, max_rt: 53.733, 12668|50.420, 1267|35.846, 1266|58.292, 1267|37.421
  30, trx: 13269, 95%: 6.806, 99%: 13.126, max_rt: 41.425, 13267|27.968, 1327|32.242, 1327|40.529, 1327|29.580
  40, trx: 12721, 95%: 7.265, 99%: 15.223, max_rt: 60.368, 12721|42.837, 1271|34.567, 1272|64.284, 1272|22.947
  50, trx: 12573, 95%: 7.185, 99%: 14.624, max_rt: 48.607, 12573|45.345, 1258|41.104, 1258|54.022, 1257|26.626

Where:

• 10 - the seconds from the start of the benchmark
• trx: 12920 - New Order transactions executed during the gived interval (in this case, for the previous 10 sec). Basically this is the throughput per interval. The more the better
• 95%: 9.483: - The 95% Response time of New Order transactions per given interval. In this case it is 9.483 sec
• 99%: 18.738: - The 99% Response time of New Order transactions per given interval. In this case it is 18.738 sec
• max_rt: 213.169: - The Max Response time of New Order transactions per given interval. In this case it is 213.169 sec
• the rest: 12919|98.778, 1292|101.096, 1293|443.955, 1293|670.842 is throughput and max response time for the other kind of transactions and can be ignored

tpcc-mysql's Issues

mac os compile error

cc -w -O3 -g -I. mysql_config --include -c load.c
cc -w -O3 -g -I. mysql_config --include -c support.c
cc load.o support.o mysql_config --libs_r -lrt -o ../tpcc_load
ld: library not found for -lrt
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [../tpcc_load] Error 1

occurred llibrary not found for -lssl when make source code for mac,how to do for this

make
cc load.o support.o `mysql_config --libs_r` -lrt -o ../tpcc_load
ld: library not found for -lssl
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [../tpcc_load] Error 1

c_new_data never used in file src/payment.c

when bind param，use the old c_data，never use c_new_data

join test

how much data is created, and how long ?

our hope is to show how well several tables can be joined and the joined result updated.
as the tables are changing.

will that be possible ?

SSL support

MySQL 5.7 support ssl connect，but tpcc-mysql don't support.

Uninitialized data in the loader

Not all data in the array has been initialized
for (i = 0; i < MAXITEMS / 10; i++)
orig[i] = 0;
I think use
int orig[MAXITEMS+1] = {0};
is better.

It was found by valgrind.

New-Order always show NG

compile and load with WH=2,
run simple test, warm 10min, run 60min.

always got New-Order [NG] in result.

But it's ok when use previous version.

error at thread_main

when use command "./tpcc_start -hlocalhost -P3306 -dtpcc150 -w150 -uroot -p "" -c8 -r300 -l1800". the error message show up "error at thread_main". Use the -c1 or do not use the option, it works well.

What is the best configuration?

Hi,
I'm using tpcc-mysql to benchmark a three-node Galera cluster, But every time that I run the test the result is different! Do you know what is the best configuration for the ./tpcc_start?
I'm using this :
./tpcc_start -hnode1 -dtpcc -uroot -w100 -c25 -r20 -i1 -l600

Thank you,
Vahid

group replication needs primary key .

Hi:
with mysql 5.7.17, group_replication, tables must have primary key.
please help fix this..
thanks very much.

Unit second of Response time

What is unit second of 95%, 99% response time in output result?

hv problem about load data

the warehouses is 100，i do not know what is the matter，how can i solve the problem，thx！！！O(∩_∩)O

Response time measurement is broken

The response time seems to be milliseconds instead of seconds.

We can see the reported time is WAY bigger than the report interval:

  [warehouse]: 1
 [connection]: 1
     [rampup]: 10 (sec.)
    [measure]: 60 (sec.)

RAMP-UP TIME.(10 sec.)

MEASURING START.

   1, trx: 38, 95%: 19.054, 99%: 20.400, max_rt: 23.462, 37|49.750, 4|2.012, 4|47.448, 5|48.571
   2, trx: 40, 95%: 19.180, 99%: 21.549, max_rt: 21.550, 42|9.995, 3|1.507, 4|41.380, 3|43.022
   3, trx: 38, 95%: 18.850, 99%: 20.073, max_rt: 20.075, 38|6.083, 4|1.796, 3|44.210, 5|46.763
   4, trx: 39, 95%: 19.575, 99%: 20.031, max_rt: 20.029, 38|5.523, 4|1.620, 4|40.641, 4|42.997
   5, trx: 41, 95%: 18.066, 99%: 20.480, max_rt: 20.479, 42|5.633, 5|1.637, 4|40.173, 3|44.047
   6, trx: 36, 95%: 19.336, 99%: 20.073, max_rt: 20.074, 37|7.212, 3|1.645, 4|43.032, 4|45.687
   7, trx: 40, 95%: 18.158, 99%: 18.941, max_rt: 18.942, 40|5.775, 5|1.682, 4|40.240, 4|47.486
   8, trx: 40, 95%: 18.760, 99%: 19.267, max_rt: 19.264, 38|4.418, 3|2.970, 4|41.314, 3|42.710
   9, trx: 38, 95%: 19.400, 99%: 20.720, max_rt: 20.723, 39|6.707, 4|1.742, 4|42.198, 5|44.275
  10, trx: 39, 95%: 19.353, 99%: 20.031, max_rt: 20.032, 36|5.718, 4|1.590, 3|40.970, 4|44.543
  11, trx: 38, 95%: 18.104, 99%: 19.020, max_rt: 19.020, 44|5.699, 4|1.529, 4|41.297, 4|46.835
  12, trx: 40, 95%: 19.077, 99%: 19.799, max_rt: 19.796, 33|11.647, 3|2.102, 5|49.200, 3|46.795
  13, trx: 39, 95%: 18.022, 99%: 19.295, max_rt: 19.298, 43|6.350, 4|1.416, 3|40.375, 5|45.496
  14, trx: 40, 95%: 19.516, 99%: 20.683, max_rt: 20.681, 43|5.311, 4|1.558, 4|39.124, 3|43.984
  15, trx: 39, 95%: 19.180, 99%: 20.596, max_rt: 20.595, 34|6.360, 4|1.617, 5|43.031, 4|44.889
  16, trx: 41, 95%: 18.833, 99%: 19.330, max_rt: 19.329, 42|5.984, 5|1.550, 3|41.493, 4|45.155
  17, trx: 37, 95%: 19.180, 99%: 21.178, max_rt: 21.181, 37|5.062, 3|1.474, 4|43.459, 4|43.914
  18, trx: 41, 95%: 18.833, 99%: 19.094, max_rt: 19.096, 44|7.158, 4|1.604, 4|37.431, 4|45.661
  19, trx: 39, 95%: 18.997, 99%: 20.067, max_rt: 20.069, 36|7.481, 4|1.569, 4|40.849, 4|43.871
  20, trx: 41, 95%: 18.941, 99%: 19.900, max_rt: 19.898, 39|4.501, 4|1.582, 4|45.777, 4|43.360
...

And even bigger than the total run time:

  [warehouse]: 1
 [connection]: 10
     [rampup]: 10 (sec.)
    [measure]: 60 (sec.)

RAMP-UP TIME.(10 sec.)

MEASURING START.

   1, trx: 85, 95%: 53.087, 99%: 69.646, max_rt: 248.682, 84|281.659, 8|9.360, 8|150.075, 8|166.969
   2, trx: 107, 95%: 59.732, 99%: 71.377, max_rt: 90.132, 105|96.892, 10|6.114, 11|111.111, 10|178.489
   3, trx: 103, 95%: 54.455, 99%: 70.930, max_rt: 84.639, 100|102.048, 11|4.509, 11|112.294, 10|133.507
   4, trx: 101, 95%: 44.042, 99%: 49.599, max_rt: 51.692, 103|109.179, 10|8.071, 10|94.886, 11|304.122
   5, trx: 107, 95%: 52.707, 99%: 57.041, max_rt: 57.193, 105|82.368, 11|12.590, 10|103.049, 11|123.099
   6, trx: 111, 95%: 55.725, 99%: 71.356, max_rt: 80.031, 111|81.273, 11|14.588, 11|129.892, 11|153.645
   7, trx: 107, 95%: 56.803, 99%: 65.993, max_rt: 77.392, 106|80.115, 10|2.139, 11|136.094, 10|135.719
   8, trx: 101, 95%: 49.422, 99%: 58.162, max_rt: 65.192, 102|89.044, 11|4.108, 10|138.442, 11|133.251
   9, trx: 106, 95%: 57.728, 99%: 62.850, max_rt: 75.334, 106|80.936, 10|4.417, 10|114.998, 10|136.289
  10, trx: 107, 95%: 53.598, 99%: 63.304, max_rt: 70.591, 112|85.523, 11|6.529, 11|97.303, 11|144.880
  11, trx: 110, 95%: 63.684, 99%: 77.293, max_rt: 77.998, 103|95.891, 11|3.538, 11|153.217, 11|148.815
  12, trx: 108, 95%: 53.326, 99%: 77.177, max_rt: 78.426, 107|108.577, 10|3.825, 11|120.383, 10|150.871
  13, trx: 103, 95%: 44.921, 99%: 52.738, max_rt: 65.801, 103|88.636, 11|4.871, 9|107.686, 11|88.867
  14, trx: 102, 95%: 52.345, 99%: 61.455, max_rt: 67.663, 103|82.450, 10|10.045, 11|115.128, 11|156.847
  15, trx: 98, 95%: 50.589, 99%: 60.163, max_rt: 62.145, 96|129.893, 10|3.197, 10|101.315, 9|116.530
  16, trx: 97, 95%: 49.466, 99%: 62.869, max_rt: 63.618, 103|88.760, 10|5.662, 10|93.754, 9|117.029
  17, trx: 98, 95%: 44.306, 99%: 49.972, max_rt: 52.833, 100|129.102, 10|3.362, 10|95.633, 10|147.868
  18, trx: 106, 95%: 50.726, 99%: 59.947, max_rt: 60.412, 101|88.115, 10|6.946, 10|99.145, 11|125.987
  19, trx: 108, 95%: 54.227, 99%: 57.195, max_rt: 64.283, 108|103.297, 10|6.999, 11|88.397, 11|166.613
  20, trx: 105, 95%: 53.662, 99%: 85.063, max_rt: 85.103, 105|88.827, 11|5.467, 10|109.460, 10|111.302
...

And my db has long_query_time = 0.1 yet there's nothing in the slow log.

---

If it's indeed milliseconds, then the final reports and checks are incorrect.

<Raw Results>
  [0] sc:0 lt:6271  rt:0  fl:0 avg_rt: 34.0 (5)
  [1] sc:1 lt:6267  rt:0  fl:0 avg_rt: 55.6 (5)
  [2] sc:597 lt:29  rt:0  fl:0 avg_rt: 2.8 (5)
  [3] sc:257 lt:370  rt:0  fl:0 avg_rt: 101.6 (80)
  [4] sc:0 lt:626  rt:0  fl:0 avg_rt: 116.4 (20)
 in 60 sec.

...
 [response time (at least 90% passed)]
      New-Order: 0.00%  [NG] *
        Payment: 0.02%  [NG] *
   Order-Status: 95.37%  [OK]
       Delivery: 40.99%  [NG] *
    Stock-Level: 0.00%  [NG] *

---

Here seems to be the problem?

rt = (double)(tbuf2.tv_sec * 1000.0 + tbuf2.tv_nsec/1000000.0-tbuf1.tv_sec * 1000.0 - tbuf1.tv_nsec/1000000.0);

https://github.com/Percona-Lab/tpcc-mysql/blob/master/src/driver.c#L141

total_rt[0] += rt;

https://github.com/Percona-Lab/tpcc-mysql/blob/master/src/driver.c#L149

    printf("  [%d] sc:%d lt:%d  rt:%d  fl:%d avg_rt: %.1f (%d)\n",
           i, success[i], late[i], retry[i], failure[i],
           total_rt[i] / (success[i] + late[i]), rt_limit[i]);

https://github.com/Percona-Lab/tpcc-mysql/blob/master/src/main.c#L534

---

Similar issues:

#6, 2016-10
tpcc-mysql 基准压测问题, 2017-09

can i change number of transactions in tpcc-mysql?

Hi, i want to test how many write requests occur with the amount of queries fixed.
Can i change number of transactions or amount of queries in tpcc-mysql?
i am finding some information. but i can't find it... please help me...

Describe output file format

In my tests, gnuplot graphs something like this :

So I looked for the output format of tpcc test and couldn't find it

How to setup if MySQL has been installed using Binaries?

I am running into errors while
shell> make.
Errors like:

• Not able to find mysql.h
• /usr/bin/ld: cannot find -lmysqlclient

and so on. It would be easier if some instructions to make specifically concerning Binary installed MySQL server were also uploaded. Thank you.

tpcc-mysql fails to compile against libmysqlclient.so.20.3.8

When compiling against 5.7.21 we got the following error:

cc load.o support.o `mysql_config --libs_r` -lrt -o ../tpcc_load
/usr/lib64/mysql/libmysqlclient.so: undefined reference to `[email protected]'
/usr/lib64/mysql/libmysqlclient.so: undefined reference to `[email protected]'
collect2: error: ld returned 1 exit status
make: *** [../tpcc_load] Error 1

This was corrected by downgrading libmysqlclient to libmysqlclient.so.18

Constraint Check Problem

Hi,
I'm using tpcc-mysql with 100 warehouses and 128 clients. I made lots of variation in parameters but one part of the results is always the same, especially in response time and those [NG]*. What's the problem? What is the meaning of those NGs?

(all must be [OK])
[transaction percentage]
Payment: 43.48% (>=43.0%) [OK]
Order-Status: 4.35% (>= 4.0%) [OK]
Delivery: 4.35% (>= 4.0%) [OK]
Stock-Level: 4.35% (>= 4.0%) [OK]
[response time (at least 90% passed)]
New-Order: 0.02% [NG] *
Payment: 0.00% [NG] *
Order-Status: 47.70% [NG] *
Delivery: 0.00% [NG] *
Stock-Level: 11.31% [NG] *

Best,
Vahid