Tpcc-mysql 结果解读
原文：https://blog.csdn.net/frockee/article/details/87812329 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）。
扫码关注我们
微信号：SRE实战
拒绝背锅 运筹帷幄
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）。
更多精彩
