TiDB正式线上前,总是要对TiDB做个压测来为后续的业务接入做评估依旧;本次针对TiDB 5.0以及MySQL 8.0在同等规格配置下,性能做一个对比,尽管来说这么对比,可比性不是很强,但是起码能为后续业务的接入以及上线有一个理论依旧;
测试环境
TiDB 5.0集群(3 TiDB,3 PD,3~5 TiKV 【16C16G】)
MySQL 8.0 主从环境【16C16G】
测试方案
1、通过 Sysbench 导入 10 张表,每张表有 1000 万行数据。
2、压测线程:16,32,64,128
3、对每个表执行 analyze table 命令。
4、使用 Sysbench 进行 point_select、read_write 测试。单轮预热 1 分钟,测试时间30分钟。
TiKV v5.0 参数配置
storage.scheduler-worker-pool-size: 5
raftstore.store-pool-size: 3
raftstore.apply-pool-size: 3
rocksdb.max-background-jobs: 8
raftdb.max-background-jobs: 4
raftdb.allow-concurrent-memtable-write: true
server.grpc-concurrency: 6
readpool.unified.min-thread-count: 5
readpool.unified.max-thread-count: 20
readpool.storage.normal-concurrency: 10
pessimistic-txn.pipelined: true
server.enable-request-batch: false
测试流程
准备测试数据
./sysbench --config-file=config oltp_point_select --tables=10 --table-size=10000000 prepare
执行测试命令
./sysbench --config-file=config oltp_read_write --tables=10 --table-size=10000000 run
不同线程测试结果对比
线程数/QPS | 16 | 32 | 64 | 128 |
TiDB(3个TiKV) | 16117.78 | 20248.98 | 21868.97 | 23389.03 |
TiDB(4个TiKV) | 15908.46 | 19708.92 | 21425.77 | 23425.17 |
TiDB(5个TiKV) | 16008.85 | 19758.88 | 21491.36 | 22925.59 |
MySQL 8.0 | 50089.04 | 67339.98 | 86560.56 | 92353.55 |
从上面的测试结果,可以看到针对单个TiDB节点测试,同样配置、相同线程下,TiDB集群的QPS要远远低于MySQL 8.0;
那么我们看下压测过程中系统负载及IO情况:
# TiDB
#MySQL 8.0
从监控结果看 ,TiDB集群无论从系统负载还是IO层面看,都没有饱和,而MySQL主机的负载已经非常的高,IO完全跑满;
接下来,我们通过HAproxy对TiDB Server节点进行负载均衡,然后进行压测,下面是压测结果:
线程数/QPS | 16 | 32 | 64 | 128 |
TiDB(3个TiKV) | 16117.78 | 20248.98 | 21868.97 | 23389.03 |
TiDB(4个TiKV) | 15908.46 | 19708.92 | 21425.77 | 23425.17 |
TiDB(5个TiKV) | 16008.85 | 19758.88 | 21491.36 | 22925.59 |
MySQL 8.0 | 50089.04 | 67339.98 | 86560.56 | 92353.55 |
HAProxy-TiDB | 36346.55 | 51929.55 | 60201.5 | 63767.53 |
从测试结果看,从TiDB Server在负载均衡的情况,整个TiDB集群的资源使用情况有所提高,QPS对比单个TiDB Server节点有明显的提高,而且节点的负载基本差不多,网络吞吐量明显提高;
综合单个Server和Server之间负载均衡的测试结果看,负载均衡要比单个TiDB Server的资源使用率高,QPS要高很多,所以推荐负载均衡的使用模式;
好了,今天就先介绍这么多吧,针对TiDB性能等方面,后续再进行介绍;