Tpcc-mysql 结果解读

1. 填坑经验

 

不要使用tidb的tpcc测试程序（非标准，tidb修改过），使用：

https://github.com/Percona-Lab/tpcc-mysql

 

2. tpcc介绍

TPC-C 模拟了一个比较有代表意义的 OLTP 应用环境：在线订单处理系统。假设有一个大型商品批发商，拥有 N 个位于不同区域的仓库，每个仓库负责为 10 个销售点供货，每个销售点有 3000 个客户，每个客户平均一个订单有 10 项产品。由于一个仓库中不可能 存储公司所有的货物，有一些请求必须发往其它仓库，因此，数据库在逻辑上是 分布的。N 是一个可变参数，测试者可以随意改变 N，以获得最佳测试效果。

tpcc有5种事务，测试完成后会输出这5种事务的吞吐量和延迟。这5种事务是：

New-Order： 客户输入一笔新的订货交易

Payment：更新客户账户余额以反应其支付状况

Delivery：发货（批处理交易）

Order-Status：查询客户最近交易的状态

Stock-Level：查询仓库库存状况，以便能够及时补货。

而业内关注的tpcc核心性能指标只有2个，就是New-Order事务的吞吐量（tpm）和延迟。 其原因是tpcc委员会制定tpcc时， 重点是考量数据库对新订单的处理能力，以揭示该数据库的商业成本。 数据库整体报价/tpm = 每个订单的数据库成本。 这个指标对衡量一款数据库的性价比，具有非常实际的指导作用；

tpcc模拟的是在线订单处理系统。为了更加仿真实际的业务系统，除了New-Order这种事务，tpcc还引入了其他4种事务，并规定：任何一款实现tpcc测试标准的测试程序，其他4种事务，在总体事务中的占比必须不少于：

```
Payment：43%
Delivery：4%
Order-Status：4%
Stock-Level：4%
```

3.结果说明

tpcc-mysql完整跑下来，输出结果是：

```
MEASURING START.

  10, trx: 7688, 95%: 37.412, 99%: 51.629, max_rt: 96.649, 7691|83.015, 769|13.419, 769|91.254, 768|161.849
  20, trx: 7788, 95%: 35.259, 99%: 47.493, max_rt: 75.225, 7789|74.724, 779|12.381, 779|75.441, 780|162.908
  30, trx: 7838, 95%: 35.492, 99%: 49.808, max_rt: 83.075, 7837|68.275, 784|10.262, 783|87.521, 781|177.636

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

<Raw Results>
  [0] sc:0 lt:23315  rt:0  fl:0 avg_rt: 27.2 (5)
  [1] sc:11414 lt:11903  rt:0  fl:0 avg_rt: 11.7 (5)
  [2] sc:2313 lt:19  rt:0  fl:0 avg_rt: 2.8 (5)
  [3] sc:2328 lt:3  rt:0  fl:0 avg_rt: 51.3 (80)
  [4] sc:0 lt:2329  rt:0  fl:0 avg_rt: 105.2 (20)
 in 30 sec.

<Raw Results2(sum ver.)>
  [0] sc:0  lt:23316  rt:0  fl:0 
  [1] sc:11414  lt:11903  rt:0  fl:0 
  [2] sc:2313  lt:19  rt:0  fl:0 
  [3] sc:2328  lt:3  rt:0  fl:0 
  [4] sc:0  lt:2329  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.34% (>= 4.0%) [OK]
 [response time (at least 90% passed)]
      New-Order: 0.00%  [NG] *
        Payment: 48.95%  [NG] *
   Order-Status: 99.19%  [OK]
       Delivery: 99.87%  [OK]
    Stock-Level: 0.00%  [NG] *

<TpmC>
                 46630.000 TpmC
```

下面分别解释：

 

3.1 10s内各事务执行情况

```
10, trx: 7688, 95%: 37.412, 99%: 51.629, max_rt: 96.649, 7691|83.015, 769|13.419, 769|91.254, 768|161.849
```

每10s钟输出1条结果。其中：

7688 表示10s内处理完成的New-Order事务的数量

95%: 37.412： 表示95% New-Order事务的请求延迟在37.12ms以内

99%: 51.629： 表示95% New-Order事务的请求延迟在51.629ms以内

max_rt: 96.649 表示New-Order事务的最大请求延迟为96.649

7691|83.015： 表示10s内，Payment事务的处理数量和95%事务的请求延迟

769|13.419： 表示10s内，Delivery事务的处理数量和95%事务的请求延迟

769|91.254： 表示10s内，Order-Status事务的处理数量和95%事务的请求延迟

768|161.849： 表示10s内，Stock-Level事务的处理数量和95%事务的请求延迟

 

3.2 压测结束后第一次统计结果

```
<Raw Results>
  [0] sc:0 lt:23315  rt:0  fl:0 avg_rt: 27.2 (5)
  [1] sc:11414 lt:11903  rt:0  fl:0 avg_rt: 11.7 (5)
  [2] sc:2313 lt:19  rt:0  fl:0 avg_rt: 2.8 (5)
  [3] sc:2328 lt:3  rt:0  fl:0 avg_rt: 51.3 (80)
  [4] sc:0 lt:2329  rt:0  fl:0 avg_rt: 105.2 (20)
 in 30 sec.
```

表示tpcc事务执行期间，5种事务执行情况。其中：

sc: 表示执行成功且请求延时在最大阀值之内（5ms）的事务数

lt: 表示执行成功，但请求延时在最大阀值之外（5ms）的事务数

rt: 表示通过重试后执行成功的事务数

fl: 表示执行失败的事务数

avg_rt: 表示事务的平均处理延迟

### 压测结束后第二次统计结果

```
<Raw Results2(sum ver.)>
  [0] sc:0  lt:23316  rt:0  fl:0 
  [1] sc:11414  lt:11903  rt:0  fl:0 
  [2] sc:2313  lt:19  rt:0  fl:0 
  [3] sc:2328  lt:3  rt:0  fl:0 
  [4] sc:0  lt:2329  rt:0  fl:0 
```

为什么会有第二次统计结果？ 根本原因是出于尽可能让tpcc高性能执行，又能做统计的考虑。

第一次统计结果中，在每次事务执行结束后，将sc、rt等变量++， 最后输出其统计结果； 在++时，并不会对sc、rt等进行并发安全保护；任何线程执行完成之后，直接++即可；

但这种做法毕竟存在一定的误差。为了修复这个问题，tpcc-mysql为每一个工作线程，内置了一套sc、rt 变量。 在执行结束后，把所有工作线程的这些变量值累加然后输出；可见，这种做法是不会存在误差的。

 

3.3 根据预置的结果阀值对结果进行分析

```
<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.34% (>= 4.0%) [OK]
 [response time (at least 90% passed)]
      New-Order: 0.00%  [NG] *
        Payment: 48.95%  [NG] *
   Order-Status: 99.19%  [OK]
       Delivery: 99.87%  [OK]
    Stock-Level: 0.00%  [NG] *
```

tpcc对每一种事务的比例有要求，因此 transaction percentage 这个检查项，是用来检查tpcc测试结束后，每一种事务所在的比例是否合乎要求。

tpcc-mysql 规定了每一种事务的最大请求延迟。在 Raw Results 最后的括号中，为5、5、5、80、20。 tpcc-mysql要求，每一种事务必须有90%的事务的请求延迟，在这个规定范围内。如果达到要求这报告ok，否则则报告错误。从上面内容可见，只有Order-Status、Delivery这两种事务符合要求，其他三种都不满足（NG）。