【作者】@seiang
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
测试流程
准备测试数据
执行测试命令
测试结果
不同线程测试结果对比
线程数/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性能等方面，后续再进行介绍。
也欢迎关注作者的个人微信公众号：
