目录
1、安装bench工具
2、插入数据
3、运行测试
4、测试结果分析
4.1、总体性能概览
4.2、事务类型详细性能
4.3、错误事务分析
4.4、结论与建议
5、清理测试数据
TPC-C 是一个对 OLTP（联机交易处理）系统进行测试的规范，使用一个商品销售模型对 OLTP 系统进行测试，其中包含五类事务：
- NewOrder – 新订单的生成
- Payment – 订单付款
- OrderStatus – 最近订单查询
- Delivery – 配送
- StockLevel – 库存缺货状态分析
在测试开始前，TPC-C Benchmark 规定了数据库的初始状态，也就是数据库中数据生成的规则，其中 ITEM 表中固定包含 10 万种商品，仓库的数量可进行调整，假设 WAREHOUSE 表中有 W 条记录，那么：
- STOCK 表中应有 W * 10 万条记录（每个仓库对应 10 万种商品的库存数据）
- DISTRICT 表中应有 W * 10 条记录（每个仓库为 10 个地区提供服务）
- CUSTOMER 表中应有 W * 10 * 3000 条记录（每个地区有 3000 个客户）
- HISTORY 表中应有 W * 10 * 3000 条记录（每个客户一条交易历史）
- ORDER 表中应有 W * 10 * 3000 条记录（每个地区 3000 个订单），并且最后生成的 900 个订单被添加到 NEW-ORDER 表中，每个订单随机生成 5 ~ 15 条 ORDER-LINE 记录。
TPC-C 使用 tpmC 值 (Transactions per Minute) 来衡量系统最大有效吞吐量 (MQTh, Max Qualified Throughput)，其中 Transactions 以 NewOrder Transaction 为准，即最终衡量单位为每分钟处理的新订单数。
1、安装bench工具
tiup install bench
错误如下：
The component `bench` not found (may be deleted from repository); skipped
由于在前面章节，采用离线方式部署tiup及tidb，不知道是否是这个原因导致无法安装
将tidb-community-toolkit-v8.1.0-linux-amd64 工具包中的 bench-v1.12.0-linux-amd64.tar.gz
复制到另一个位置后解压，然后配置环境变量。
在前面章节中，我的环境配置文件在 /home/tidb/.bashrc 中，
cd /home/tidb
mkdir bench
cd bench
tar -zxf bench-v1.12.0-linux-amd64.tar.gz
# 依据个人实际的环境变量位置 ，在线的方式 可能是 /root/.bashrc
vim /home/tidb/.bashrc结尾处添加配置
export PATH=/home/tidb/bench:$PATH然后执行
source /homt/tidb/.bashrc2、插入数据
如果部署多个tidb-server服务，且端口都为4000，则命令中的IP可以用逗号隔开。
如 192.168.20.113, 192.168.20.114
cd /home/tidb/benchtiup-bench tpcc -H 192.168.20.113 -P 4000 -U root -p 123456 -D tpcc --warehouses 100 --threads 20 prepare其中参数：
--warehouses 100 表示执行100个批次，一个批次数据以文章最开始的表格数据
--threads 20 开启20 线程同时操作。
-D tpcc 数据库实例名
最终数据结果
数据导入完成后，可以通过命令 验证数据正确性。
tiup bench tpcc -H 192.168.20.113 -P 4000 -D tpcc --warehouses 4 check
3、运行测试
tiup-bench tpcc -H 192.168.20.113 -P 4000 -U root -p 123456 -D tpcc --warehouses 100 --threads 100 --time 10m run运行过程中控制台上会持续打印测试结果：
[Current] DELIVERY - Takes(s): 10.0, Count: 116, TPM: 698.9, Sum(ms): 37024.4, Avg(ms): 319.1, 50th(ms): 302.0, 90th(ms): 436.2, 95th(ms): 570.4, 99th(ms): 939.5, 99.9th(ms): 939.5, Max(ms): 939.5
[Current] NEW_ORDER - Takes(s): 10.0, Count: 1386, TPM: 8318.0, Sum(ms): 410842.4, Avg(ms): 296.3, 50th(ms): 251.7, 90th(ms): 486.5, 95th(ms): 637.5, 99th(ms): 906.0, 99.9th(ms): 1342.2, Max(ms): 1342.2
[Current] ORDER_STATUS - Takes(s): 10.0, Count: 126, TPM: 757.6, Sum(ms): 869.9, Avg(ms): 6.9, 50th(ms): 6.8, 90th(ms): 8.9, 95th(ms): 10.5, 99th(ms): 14.7, 99.9th(ms): 16.3, Max(ms): 16.3
[Current] PAYMENT - Takes(s): 10.0, Count: 1327, TPM: 7963.8, Sum(ms): 546047.8, Avg(ms): 411.6, 50th(ms): 352.3, 90th(ms): 704.6, 95th(ms): 872.4, 99th(ms): 1275.1, 99.9th(ms): 1543.5, Max(ms): 1610.6
[Current] STOCK_LEVEL - Takes(s): 10.0, Count: 137, TPM: 823.2, Sum(ms): 3402.9, Avg(ms): 24.9, 50th(ms): 10.0, 90th(ms): 15.2, 95th(ms): 130.0, 99th(ms): 243.3, 99.9th(ms): 302.0, Max(ms): 302.0[Current] DELIVERY - Takes(s): 10.0, Count: 123, TPM: 740.3, Sum(ms): 35960.9, Avg(ms): 292.4, 50th(ms): 251.7, 90th(ms): 453.0, 95th(ms): 604.0, 99th(ms): 973.1, 99.9th(ms): 1040.2, Max(ms): 1040.2
[Current] NEW_ORDER - Takes(s): 10.0, Count: 1242, TPM: 7474.8, Sum(ms): 388801.1, Avg(ms): 313.2, 50th(ms): 260.0, 90th(ms): 536.9, 95th(ms): 704.6, 99th(ms): 1208.0, 99.9th(ms): 1610.6, Max(ms): 1610.6
[Current] ORDER_STATUS - Takes(s): 10.0, Count: 106, TPM: 638.4, Sum(ms): 766.2, Avg(ms): 7.2, 50th(ms): 6.8, 90th(ms): 9.4, 95th(ms): 14.7, 99th(ms): 18.9, 99.9th(ms): 21.0, Max(ms): 21.0
[Current] PAYMENT - Takes(s): 10.0, Count: 1243, TPM: 7472.7, Sum(ms): 571087.3, Avg(ms): 459.4, 50th(ms): 385.9, 90th(ms): 805.3, 95th(ms): 1040.2, 99th(ms): 1677.7, 99.9th(ms): 2415.9, Max(ms): 2818.6
[Current] STOCK_LEVEL - Takes(s): 9.9, Count: 111, TPM: 673.1, Sum(ms): 3125.7, Avg(ms): 28.1, 50th(ms): 11.0, 90th(ms): 65.0, 95th(ms): 113.2, 99th(ms): 285.2, 99.9th(ms): 570.4, Max(ms): 570.4
最终测试报告
Finished
[Summary] DELIVERY - Takes(s): 599.7, Count: 6732, TPM: 673.5, Sum(ms): 2229639.0, Avg(ms): 331.4, 50th(ms): 302.0, 90th(ms): 503.3, 95th(ms): 637.5, 99th(ms): 939.5, 99.9th(ms): 1677.7, Max(ms): 2013.3
[Summary] NEW_ORDER - Takes(s): 599.9, Count: 74459, TPM: 7447.3, Sum(ms): 24556150.5, Avg(ms): 329.9, 50th(ms): 285.2, 90th(ms): 570.4, 95th(ms): 771.8, 99th(ms): 1275.1, 99.9th(ms): 2415.9, Max(ms): 4160.7
[Summary] NEW_ORDER_ERR - Takes(s): 599.9, Count: 23, TPM: 2.3, Sum(ms): 3316.2, Avg(ms): 144.5, 50th(ms): 151.0, 90th(ms): 251.7, 95th(ms): 704.6, 99th(ms): 872.4, 99.9th(ms): 872.4, Max(ms): 872.4
[Summary] ORDER_STATUS - Takes(s): 600.0, Count: 6703, TPM: 670.3, Sum(ms): 53463.5, Avg(ms): 8.0, 50th(ms): 7.3, 90th(ms): 10.0, 95th(ms): 13.1, 99th(ms): 18.9, 99.9th(ms): 159.4, Max(ms): 520.1
[Summary] PAYMENT - Takes(s): 599.9, Count: 71659, TPM: 7167.0, Sum(ms): 32908219.3, Avg(ms): 459.5, 50th(ms): 369.1, 90th(ms): 872.4, 95th(ms): 1140.9, 99th(ms): 1879.0, 99.9th(ms): 3221.2, Max(ms): 6174.0
[Summary] PAYMENT_ERR - Takes(s): 599.9, Count: 42, TPM: 4.2, Sum(ms): 10898.3, Avg(ms): 259.2, 50th(ms): 251.7, 90th(ms): 570.4, 95th(ms): 570.4, 99th(ms): 771.8, 99.9th(ms): 771.8, Max(ms): 771.8
[Summary] STOCK_LEVEL - Takes(s): 600.0, Count: 6630, TPM: 663.0, Sum(ms): 203118.1, Avg(ms): 30.7, 50th(ms): 11.5, 90th(ms): 79.7, 95th(ms): 167.8, 99th(ms): 335.5, 99.9th(ms): 604.0, Max(ms): 1409.3
[Summary] STOCK_LEVEL_ERR - Takes(s): 600.0, Count: 2, TPM: 0.2, Sum(ms): 22.2, Avg(ms): 11.3, 50th(ms): 10.0, 90th(ms): 13.1, 95th(ms): 13.1, 99th(ms): 13.1, 99.9th(ms): 13.1, Max(ms): 13.1
tpmC: 7447.3, tpmTotal: 16621.0, efficiency: 579.1%
4、测试结果分析
将测试结果交由AI分析，提示词：
以下是使用TPC-C 对TiDB服务进行压力测试结果，请分析测试结果
以下是基于提供的TPC-C压力测试结果的分析：
4.1、总体性能概览
- tpmC (New Order 事务每分钟处理次数): 7447.3
- 这是TPC-C测试中最重要的指标，代表每分钟成功处理的New Order事务数。7447.3 表示系统每分钟处理约7447个New Order事务。
- tpmTotal: 16621.0
- 这是系统总体每分钟处理的所有事务（包括其他类型的事务）的总和。
- 效率 (efficiency): 579.1%
- 这个值通常表示系统的利用率。超过100%的效率可能表示系统在超负荷运行，或者在一定程度上对事务进行了并发优化。
4.2、事务类型详细性能
-
DELIVERY
- TPM: 673.5
- 平均响应时间: 331.4ms
- 最大响应时间: 2013.3ms
- P99 响应时间: 939.5ms
- 分析: DELIVERY事务的平均响应时间和P99响应时间相对较高，表明在高负载下，可能会出现瓶颈或延迟。
-
NEW_ORDER
- TPM: 7447.3
- 平均响应时间: 329.9ms
- 最大响应时间: 4160.7ms
- P99 响应时间: 1275.1ms
- 分析: New Order事务是TPC-C测试中的关键负载类型。该事务的平均响应时间相对较好，但P99响应时间较高，可能意味着系统在高负载时有较大延迟。
-
ORDER_STATUS
- TPM: 670.3
- 平均响应时间: 8.0ms
- 最大响应时间: 520.1ms
- 分析: 这是一个相对较轻的查询操作，响应时间较低。性能表现良好。
-
PAYMENT
- TPM: 7167.0
- 平均响应时间: 459.5ms
- 最大响应时间: 6174.0ms
- P99 响应时间: 1879.0ms
- 分析: PAYMENT事务的平均响应时间和P99响应时间较高，最大响应时间超过6秒，显示了在负载下可能存在性能瓶颈。
-
STOCK_LEVEL
- TPM: 663.0
- 平均响应时间: 30.7ms
- 最大响应时间: 1409.3ms
- 分析: 作为库存查询操作，响应时间总体良好，但在极端情况下（最大响应时间）可能会有明显的延迟。
4.3、错误事务分析
- NEW_ORDER_ERR: 出现了23次错误，平均响应时间144.5ms，最大872.4ms。
- PAYMENT_ERR: 出现了42次错误，平均响应时间259.2ms，最大771.8ms。
- STOCK_LEVEL_ERR: 出现了2次错误，响应时间较低，可能是轻微的错误。
- 分析: 错误事务数量较少，说明系统在高负载下的稳定性还算不错，但仍需关注事务错误的原因。
4.4、结论与建议
-
瓶颈分析: 主要的瓶颈似乎出现在NEW_ORDER和PAYMENT事务中，尤其是在P99和最大响应时间上。可以考虑优化数据库索引、优化SQL查询、或增加硬件资源以改善高负载下的性能。
-
事务延迟: 在DELIVERY、NEW_ORDER和PAYMENT事务中的P99和最大响应时间较高，这可能会影响用户体验。建议检查这些事务的执行路径，找出潜在的延迟点。
-
系统效率: 效率为579.1%可能表示系统正在过度利用资源，或者在并发负载下有较大的优化空间。建议进一步调查系统资源的利用情况（CPU、内存、磁盘IO等），并根据需求进行调整。
-
错误事务: 错误事务数量不多，但需要详细调查这些事务失败的原因，以避免在实际生产环境中出现类似问题。
5、清理测试数据
tiup-bench tpcc -H 192.168.20.113 -P 4000 -U root -p 123456 -D tpcc --warehouses 4 cleanupDROP TABLE IF EXISTS item
DROP TABLE IF EXISTS customer
DROP TABLE IF EXISTS district
DROP TABLE IF EXISTS history
DROP TABLE IF EXISTS new_order
DROP TABLE IF EXISTS order_line
DROP TABLE IF EXISTS orders
DROP TABLE IF EXISTS stock
DROP TABLE IF EXISTS warehouse
Finished
参照文章：
如何对 TiDB 进行 TPC-C 测试 | PingCAP 文档中心
![[MRCTF2020]套娃1](https://i-blog.csdnimg.cn/direct/3058e12a995e46ebbf61426c9920b095.png)
