关于TPCC测试结果不太理解，忘旨点

xtjsxtj

服务器一：
192.168.2.56
Linux localhost.localdomain 2.6.18-274.el5xen #1 SMP Fri Jul 8 17:45:44 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
12  Intel(R) Xeon(R) CPU           E5649  @ 2.53GHz
| version                         | 5.5.21-log                    |
| version_comment                 | MySQL Community Server (GPL)  |
| version_compile_machine         | x86_64                        |
| version_compile_os              | Linux                         |
| innodb_version                  | 1.1.8                         |
| innodb_flush_log_at_trx_commit  | 0                             |
| innodb_buffer_pool_size         | 2097152000                    |
| log_bin                         | ON                            |
| sync_binlog                     | 0                             |

服务二：
192.168.2.162
Linux RFSIM 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:58:04 EST 2007 i686 i686 i386 GNU/Linux
4  Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
| version                         | 5.0.51a-community-log         |
| version_comment                 | MySQL Community Edition (GPL) |
| version_compile_machine         | i686                          |
| version_compile_os              | redhat-linux-gnu              |
| innodb_flush_log_at_trx_commit  | 0                             |
| innodb_buffer_pool_size         | 1097152000                    |
| log_bin                         | ON                            |
| sync_binlog                     | 0                             |

两台服务器都按TPCC要求建好了库和表，并且均在两台机器上编译了tpcc_start

测试一，tpcc_start运行在56，连接56机MYSQL的测试结果

[192.168.2.56]# ./tpcc_start -h 192.168.2.56 -P 3306 -d tpcc -u root -p cpyf -w 100 -c 20 -r 1800 -l 600

MEASURING START.

  10, 372(0):2.654|2.932, 378(0):0.496|0.745, 38(0):0.252|0.320, 36(0):3.088|3.318, 37(0):8.628|10.089
  20, 404(0):2.701|2.877, 400(0):0.501|0.514, 40(0):0.236|0.238, 42(0):2.986|3.078, 39(0):8.357|8.576
  30, 372(0):2.651|2.855, 380(0):0.498|0.519, 38(0):0.235|0.243, 37(0):3.119|3.146, 39(0):7.921|7.977
  40, 413(0):2.747|2.828, 403(0):0.493|0.514, 40(0):0.230|0.256, 41(0):2.993|3.068, 40(0):8.830|9.209
  50, 383(0):2.585|2.807, 387(0):0.479|0.528, 40(0):0.241|0.253, 39(0):2.955|3.089, 40(0):7.871|7.966

....................

560, 401(0):2.620|2.805, 403(0):0.498|0.517, 39(0):0.223|0.232, 39(0):3.085|3.089, 40(0):7.882|7.903
570, 385(0):2.657|2.940, 387(0):0.495|0.523, 39(0):0.232|0.238, 41(0):2.968|3.006, 41(0):8.335|8.368
580, 416(0):2.755|2.910, 409(0):0.486|0.497, 42(0):0.244|0.247, 40(0):3.038|3.105, 39(0):8.433|8.824
590, 378(0):2.658|2.685, 379(0):0.500|0.540, 37(0):0.240|0.244, 39(0):3.039|3.170, 38(0):8.640|8.738
600, 384(0):2.664|2.846, 389(0):0.495|0.523, 39(0):0.236|0.255, 37(0):3.022|3.064, 39(0):8.597|8.602

STOPPING THREADS....................

<Raw Results>
  [0] sc:22226  lt:0  rt:0  fl:0
  [1] sc:22232  lt:0  rt:0  fl:0
  [2] sc:2224  lt:0  rt:0  fl:0
  [3] sc:2222  lt:0  rt:0  fl:0
  [4] sc:2222  lt:0  rt:0  fl:0
in 600 sec.

<Raw Results2(sum ver.)>
  [0] sc:22227  lt:0  rt:0  fl:0
  [1] sc:22232  lt:0  rt:0  fl:0
  [2] sc:2224  lt:0  rt:0  fl:0
  [3] sc:2222  lt:0  rt:0  fl:0
  [4] sc:2222  lt:0  rt:0  fl:0

<Constraint Check> (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: 100.00%  [OK]
        Payment: 100.00%  [OK]
   Order-Status: 100.00%  [OK]
       Delivery: 100.00%  [OK]
    Stock-Level: 100.00%  [OK]

<TpmC>
                 2222.600 TpmC

测试二，tpcc_start运行在56，连接162机MYSQL的测试结果

[192.168.2.56]# ./tpcc_start -h 192.168.2.162 -P 3306 -d tpcc -u root -p cpyf -w 100 -c 20 -r 600 -l 1200

MEASURING START.

  10, 205(0):2.348|2.852, 205(0):0.541|0.786, 20(0):0.290|0.429, 21(0):2.613|2.996, 18(0):7.592|7.967
  20, 202(0):2.407|2.715, 202(0):0.509|0.669, 21(0):0.277|0.279, 21(0):2.536|2.642, 22(0):7.095|7.131
  30, 185(0):2.129|2.208, 187(0):0.460|0.541, 19(0):0.224|0.256, 18(0):2.296|2.312, 18(0):6.818|7.387
  40, 205(0):2.226|2.325, 201(0):0.504|0.589, 20(0):0.197|0.248, 18(0):2.344|2.437, 21(0):6.738|6.904
  50, 202(0):2.411|2.706, 204(0):0.594|0.640, 21(0):0.246|0.301, 22(0):2.506|2.522, 20(0):7.078|7.459

  ....................

  1160, 202(0):2.283|2.394, 197(0):0.480|0.505, 20(0):0.223|0.272, 20(0):2.698|2.784, 21(0):7.152|7.237
  1170, 200(0):2.458|2.605, 205(0):0.495|0.588, 20(0):0.226|0.229, 21(0):2.561|2.640, 16(0):7.431|7.559
  1180, 224(0):2.276|2.565, 223(0):0.497|0.533, 23(0):0.230|0.291, 21(0):2.387|2.451, 25(0):7.263|7.330
  1190, 203(0):2.186|2.617, 199(0):0.467|0.525, 20(0):0.230|0.238, 20(0):2.437|2.469, 20(0):6.822|7.207
  1200, 193(0):2.403|2.576, 196(0):0.498|0.553, 20(0):0.224|0.271, 20(0):2.270|2.428, 20(0):7.057|7.315

STOPPING THREADS....................

<Raw Results>
  [0] sc:24481  lt:0  rt:0  fl:0
  [1] sc:24482  lt:0  rt:0  fl:0
  [2] sc:2449  lt:0  rt:0  fl:0
  [3] sc:2448  lt:0  rt:0  fl:0
  [4] sc:2447  lt:0  rt:0  fl:0
in 1200 sec.

<Raw Results2(sum ver.)>
  [0] sc:24481  lt:0  rt:0  fl:0
  [1] sc:24482  lt:0  rt:0  fl:0
  [2] sc:2449  lt:0  rt:0  fl:0
  [3] sc:2448  lt:0  rt:0  fl:0
  [4] sc:2447  lt:0  rt:0  fl:0

<Constraint Check> (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: 100.00%  [OK]
        Payment: 100.00%  [OK]
   Order-Status: 100.00%  [OK]
       Delivery: 100.00%  [OK]
    Stock-Level: 100.00%  [OK]

<TpmC>
                 1224.050 TpmC

从测试一与测试二比较来看，56MYSQL要比162MYSQL性能强，除硬件操作系统外，MYSQL5.5及1.1版的InnoDB引擎性能优于MYSQL5.0


测试三，tpcc_start运行在162，连接56机MYSQL的测试结果

[192.168.2.162]# ./tpcc_start -h 192.168.2.56 -P 3306 -d tpcc -u root -p cpyf -w 100 -c 20 -r 1800 -l 600

MEASURING START.

  10, 388(38:19.999|4412.411, 389(265):19.999|2159.619, 39(39):19.999|3724.999, 38(3:19.999|4727.922, 40(40):19.999|3075.398
  20, 382(382):19.999|1798.228, 382(270):19.999|413.312, 38(37):19.999|377.047, 37(37):19.999|1292.126, 38(3:19.999|1024.419
  30, 370(370):19.999|1468.089, 367(244):19.999|404.887, 37(36):19.999|416.421, 38(3:19.999|1062.425, 36(36):19.999|807.229
  40, 401(401):19.999|1036.657, 399(280):19.999|415.605, 40(3:19.999|369.894, 40(40):19.999|1049.056, 40(40):19.999|730.632
  50, 371(371):19.999|1769.669, 375(254):19.999|606.400, 38(37):19.999|680.249, 37(36):19.999|1117.479, 38(3:19.999|1092.521

  ....................

560, 392(392):19.999|1503.777, 395(23:19.999|428.741, 40(39):19.999|1072.165, 38(3:19.999|1081.392, 39(39):19.999|1556.665
570, 374(374):19.999|1493.399, 373(247):19.999|396.035, 38(3:19.999|413.094, 37(36):19.999|1174.328, 38(3:19.999|1048.668
580, 348(348):19.999|1438.612, 349(217):19.999|596.789, 34(33):19.999|702.038, 37(37):19.999|1371.389, 35(35):19.999|1029.090
590, 419(419):19.999|983.874, 416(281):19.999|945.001, 41(38):19.999|791.180, 42(41):19.999|1183.393, 40(40):19.999|968.308
600, 340(340):19.999|1952.219, 339(235):19.999|732.921, 35(34):19.999|454.505, 34(34):19.999|1247.263, 35(35):19.999|1037.934

STOPPING THREADS....................

<Raw Results>
  [0] sc:0  lt:21873  rt:0  fl:0
  [1] sc:6900  lt:14971  rt:0  fl:0
  [2] sc:79  lt:2108  rt:0  fl:0
  [3] sc:18  lt:2169  rt:0  fl:0
  [4] sc:0  lt:2188  rt:0  fl:0
in 600 sec.

<Raw Results2(sum ver.)>
  [0] sc:0  lt:21873  rt:0  fl:0
  [1] sc:6900  lt:14971  rt:0  fl:0
  [2] sc:79  lt:2108  rt:0  fl:0
  [3] sc:18  lt:2169  rt:0  fl:0
  [4] sc:0  lt:2188  rt:0  fl:0

<Constraint Check> (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.00%  [NG] *
        Payment: 31.55%  [NG] *
   Order-Status: 3.61%  [NG] *
       Delivery: 0.82%  [NG] *
    Stock-Level: 0.00%  [NG] *

<TpmC>
                 2187.300 TpmC


对比测试一与测试三，数据库同为56机的MYSQL数据，只是tpcc_start运行在162上，TpmC结果值差不多，但是为何延时相差如此之多
一个是2.654|2.932，另一个是19.999|1952.219，既然延时那么多，为何10S钟内会有相同的近呼400的TPC值呢？而且为何测试三的平均延时都是19.999呢


为进一步确认问题，进行下面的测试四

测试四，，tpcc_start运行在162，连接162机MYSQL的测试结果

[192.168.2.162]# ./tpcc_start -h 192.168.2.162 -P 3306 -d tpcc -u root -p cpyf -w 100 -c 20 -r 600 -l 1200

MEASURING START.

  10, 209(209):19.999|1647.921, 206(200):19.999|967.557, 21(21):19.999|2106.025, 22(22):19.999|2720.829, 21(21):19.999|8463.733
  20, 200(200):19.999|1152.472, 204(190):19.999|593.296, 21(21):19.999|587.523, 20(20):19.999|1490.028, 19(19):19.999|6656.831
  30, 210(210):19.999|1098.082, 207(197):19.999|427.641, 20(20):19.999|1076.053, 21(21):19.999|1208.926, 24(24):19.999|5856.387
  40, 194(194):19.999|989.163, 198(187):19.999|808.818, 20(20):19.999|898.046, 20(20):19.999|1584.236, 21(21):19.999|6410.519
  50, 204(204):19.999|1414.752, 208(197):19.999|677.903, 21(21):19.999|746.640, 20(20):19.999|1153.665, 18(18):19.999|5831.981

  ....................

1160, 213(213):19.999|1126.940, 214(205):19.999|625.221, 21(21):19.999|805.167, 21(21):19.999|1253.977, 22(22):19.999|5887.219
1170, 239(239):19.999|1058.372, 233(223):19.999|602.556, 23(23):19.999|729.225, 23(23):19.999|1716.378, 24(24):19.999|5046.849
1180, 202(202):19.999|1033.164, 206(193):19.999|338.385, 21(21):19.999|677.194, 22(22):19.999|2268.507, 19(19):19.999|5612.890
1190, 203(202):19.999|1147.954, 202(193):19.999|600.369, 21(21):19.999|736.838, 19(19):19.999|2114.439, 23(23):19.999|5846.195
1200, 188(188):19.999|1025.960, 188(179):19.999|603.564, 18(18):19.999|752.963, 19(19):19.999|1333.916, 18(18):19.999|6540.843

STOPPING THREADS....................

<Raw Results>
  [0] sc:9  lt:25263  rt:0  fl:0
  [1] sc:1082  lt:24190  rt:0  fl:0
  [2] sc:2  lt:2526  rt:0  fl:0
  [3] sc:0  lt:2528  rt:0  fl:0
  [4] sc:0  lt:2529  rt:0  fl:0
in 1200 sec.

<Raw Results2(sum ver.)>
  [0] sc:9  lt:25263  rt:0  fl:0
  [1] sc:1082  lt:24190  rt:0  fl:0
  [2] sc:2  lt:2526  rt:0  fl:0
  [3] sc:0  lt:2528  rt:0  fl:0
  [4] sc:0  lt:2529  rt:0  fl:0

<Constraint Check> (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.04%  [NG] *
        Payment: 4.28%  [NG] *
   Order-Status: 0.08%  [NG] *
       Delivery: 0.00%  [NG] *
    Stock-Level: 0.00%  [NG] *

<TpmC>
                 1263.600 TpmC

对比测试三和测试四，tpcc_start即使连接本机MYSQL测试还是延时，而且还是19.999，我都怀疑是不是tpcc_start在162上运行的不正常，怎么一直是19.999

chinafenghao

@xtjsxtj
那个是延时么？我一直没找到这个手册。我一般只看第一列

xtjsxtj

回复 2# chinafenghao

tpcc_start输出结果说明

TPCC-MySQL输出结果包括五个业务逻辑，这五个业务逻辑构成了TPCC-MySQL测试的整个事务处理过程。具体如下所示：
New-Order：新订单
Payment：支付
Order-Status：订单查询
Delivery：发货
Stock-Level：库存

为了能够清晰的说明以下内容，首先定义一些变量，便于以下的计算和说明。具体如下所示：
success = 执行成功的记录数
late=执行延迟的记录数
pre_success=上一次执行成功的记录数
pre_late=上一次执行失败的记录数

根据不同的业务，late的定义也不同，五种业务逻辑分别对操作延迟定义的界限值如下所示：
New-Order       5ms
Payment         5ms
Order-Status    5ms
Delivery        80ms
Stock-Level     20ms

根据以上定义的变量，计算相应字段的结果和说明相应字段的含义。
1、时间间隔内成功的事务(包括成功和延迟的事务)：sl=success+late-pre_success-pre_late
2、时间间隔内延迟的事务：l=late-pre_late
3、时间间隔内前90%记录(实际为99%)的平均响应时间：rt90
4、时间间隔内最大的响应时间：max_rt

根据输出结果，根据以上计算和说明内容，对未说明的部分分析如下：
Count   New-Order      Payment      Order-Status      Delivery      Stock-Level
     sl(l):rt90|max_rt  sl(l):rt90|max_rt  sl(l):rt90|max_rt  sl(l):rt90|max_rt  sl(l):rt90|max_rt
#,   #(#):#|#,        #(#):#|#,         #(#):#|#,        #(#):#|#,        #(#):#|#

chinafenghao

@xtjsxtj
good