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................................
[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.
[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
[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] *
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 压测结束后第一次统计结果
```
[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: 表示事务的平均处理延迟
### 压测结束后第二次统计结果
```
[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 根据预置的结果阀值对结果进行分析
```
[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）。