title: TiDB TPC-C 性能对比测试报告 - v5.3.0 对比 v5.2.2
TiDB TPC-C 性能对比测试报告 - v5.3.0 对比 v5.2.2
测试概况
本次测试对比了 TiDB v5.3.0 和 v5.2.2 在 OLTP 场景下的 TPC-C 性能表现。结果显示,v5.3.0 相比于 v5.2.2 在 TPC-C 性能上略下降了 2.99%。
测试环境 (AWS EC2)
硬件配置
服务类型 | EC2 类型 | 实例数 |
---|---|---|
PD | m5.xlarge | 3 |
TiKV | i3.4xlarge | 3 |
TiDB | c5.4xlarge | 3 |
TPC-C | c5.9xlarge | 1 |
软件版本
服务类型 | 软件版本 |
---|---|
PD | v5.2.2、v5.3.0 |
TiDB | v5.2.2、v5.3.0 |
TiKV | v5.2.2、v5.3.0 |
TiUP | 1.5.1 |
配置参数
两个版本使用同样的配置
TiDB 参数配置
log.level: "error"
performance.max-procs: 20
prepared-plan-cache.enabled: true
tikv-client.max-batch-wait-time: 2000000
TiKV 参数配置
pessimistic-txn.pipelined: true
raftdb.allow-concurrent-memtable-write: true
raftdb.max-background-jobs: 4
raftstore.apply-max-batch-size: 2048
raftstore.apply-pool-size: 3
raftstore.store-max-batch-size: 2048
raftstore.store-pool-size: 3
readpool.storage.normal-concurrency: 10
readpool.unified.max-thread-count: 20
readpool.unified.min-thread-count: 5
rocksdb.max-background-jobs: 8
server.grpc-concurrency: 6
storage.scheduler-worker-pool-size: 20
TiDB 全局变量配置
set global tidb_hashagg_final_concurrency=1;
set global tidb_hashagg_partial_concurrency=1;
set global tidb_enable_async_commit = 1;
set global tidb_enable_1pc = 1;
set global tidb_guarantee_linearizability = 0;
set global tidb_enable_clustered_index = 1;
HAProxy 配置 - haproxy.cfg 文件
更多有关 HAProxy 在 TiDB 上的使用,可参阅 HAProxy 在 TiDB 中的最佳实践。
global # 全局配置。
chroot /var/lib/haproxy # 更改当前目录并为启动进程设置超级用户权限,从而提高安全性。
pidfile /var/run/haproxy.pid # 将 HAProxy 进程的 PID 写入 pidfile。
maxconn 4000 # 每个 HAProxy 进程所接受的最大并发连接数。
user haproxy # 同 UID 参数。
group haproxy # 同 GID 参数,建议使用专用用户组。
nbproc 64 # 在后台运行时创建的进程数。在启动多个进程转发请求时,确保该值足够大,保证 HAProxy 不会成为瓶颈。
daemon # 让 HAProxy 以守护进程的方式工作于后台,等同于命令行参数“-D”的功能。当然,也可以在命令行中用“-db”参数将其禁用。
defaults # 默认配置。
log global # 日志继承全局配置段的设置。
retries 2 # 向上游服务器尝试连接的最大次数,超过此值便认为后端服务器不可用。
timeout connect 2s # HAProxy 与后端服务器连接超时时间。如果在同一个局域网内,可设置成较短的时间。
timeout client 30000s # 客户端与 HAProxy 连接后,数据传输完毕,即非活动连接的超时时间。
timeout server 30000s # 服务器端非活动连接的超时时间。
listen tidb-cluster # 配置 database 负载均衡。
bind 0.0.0.0:3390 # 浮动 IP 和 监听端口。
mode tcp # HAProxy 要使用第 4 层的传输层。
balance roundrobin # 连接数最少的服务器优先接收连接。`leastconn` 建议用于长会话服务,例如 LDAP、SQL、TSE 等,而不是短会话协议,如 HTTP。该算法是动态的,对于启动慢的服务器,服务器权重会在运行中作调整。
server tidb-1 10.9.18.229:4000 check inter 2000 rise 2 fall 3 # 检测 4000 端口,检测频率为每 2000 毫秒一次。如果 2 次检测为成功,则认为服务器可用;如果 3 次检测为失败,则认为服务器不可用。
server tidb-2 10.9.39.208:4000 check inter 2000 rise 2 fall 3
server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3
测试方案
- 通过 TiUP 部署 TiDB v5.3.0 和 v5.2.2。
- 创建数据库 tpcc:
create database tpcc;
- 通过 tiup bench 导入 TPC-C 5000 Warehouse 数据:
tiup bench tpcc prepare --warehouse 5000 --db tpcc -H 127.0.0.1 -p 4000
。 - 运行
tiup bench tpcc run -U root --db tpcc --host 127.0.0.1 --port 4000 --time 1800s --warehouses 5000 --threads {{thread}}
命令,通过 HAProxy 向 TiDB 加压,每个并发数各测试 30 分钟。 - 从结果中提取 New Order 的 tpmC 的数据。
测试结果
v5.3.0 相比 v5.2.2 在 TPC-C 性能上略下降了 2.99%。
Threads | v5.2.2 tpmC | v5.3.0 tpmC | tpmC 提升 (%) |
---|---|---|---|
50 | 42228.8 | 41580 | -1.54 |
100 | 49400 | 48248.2 | -2.33 |
200 | 54436.6 | 52809.4 | -2.99 |
400 | 57026.7 | 54117.1 | -5.10 |