作者： duzq 原文来源：https://tidb.net/blog/cb1c5ea3

1、测试目的

TIDB 2.1 region 心跳和 raft 消息是单线程处理的，在 region 量比较大 (几十上百万) 的集群中，虽然写入量不大，但是大量的心跳导致 raft 的单线程 cpu 经常打满，进而导致业务响应时间明显增加，在 3.0 版本 raft 改成了多线程，性能有明显的提升，这里主要测试 TIDB 3.0.5 版本的性能数据。

2、测试工具

• 使用 sysbench 1.1.0 作为测试工具

• oltp 数据模型：32 张表；每张表 40000000 行数据。共使用的磁盘空间为：280G 左右。

• 默认收集 7 种负载情况下的统计数据：oltp_point_select、select_random_points、oltp_read_only、oltp_write_only、oltp_read_write、oltp_update_index、oltp_update_non_index

• 测试工具集：ssh://git\@git.xxxxxxx.com/inf/sysbench_for_tidb.git 这个 git 仓库是公司内部压测 tidb 专用的仓库，主要脚本有：

• 编译安装 sysbench 脚本

• 根据配置文件构造和清理测试数据脚本

• 根据配置文件压测某一个场景脚本

• 根据配置文件压测所有场景并生成测试日志脚本

3、测试环境

机房内 rtt min/avg/max/mdev = 0.065/0.¹¹²⁄₀.¹⁴⁶⁄₀.021 ms

4、测试场景说明

• oltp_point_select

• 主键点查 (SELECT c FROM sbtest14 WHERE id=?)

• select_random_points

• 索引点查 (SELECT id, k, c, pad FROM sbtest1 WHERE k IN (%s))

• oltp_read_only

• 复杂查询 (单个事务共 14 个语句，10 个 point select，1 个 sum，1 个范围，1 个排序，1 个 distinct)

• oltp_write_only

• 单个事务 4 个语句，1 个删除、1 个插入、1 个 update 索引和 1 个非索引列

• oltp_read_write

• oltp_read_only + oltp_write_only，1 个事务共 18 个语句

• oltp_update_index

• 根据主键更新索引列 (UPDATE sbtest%u SET k=k+1 WHERE id=?)

• oltp_update_non_index

• 根据主键更新非索引列（UPDATE sbtest%u SET c=? WHERE id=?）

5、测试步骤

1. 安装部署 tidb 和 sysbench 并授权和创建 DB

2. 构造测试数据，默认按照 建表 -> 插入数据 -> 创建索引 的顺序执行，对 tidb 而言时间会比较长，可以根据tidb 的 sysbench 优化来减少构造数据的时间

3. 修改 sysbench 配置文件，例如指定压测 TIDB 节点和端口、TIDB 账号和密码、压测的表个数和数据量、压测线程数、压测时长、每次压测的预热时间等

4. 开启 3 个 screen，分别启动 3 个 sysbench 进程压 3 个 TIDB 节点并输出到压测结果文件

5. 记录并分析压测结果

6. 压测完成后将相关配置保存后提交到新的 GIT 分支，主要包括：a.tidb 配置文件、b.tikv 配置文件、sysbench 压测参数配置文件和压测结果文档 URL 记录

6、数据记录

git 分支：remotes/origin/tidb_3.0.5_perftest

commit id：6456dcd

MIN&AVG&99TH：分别对应事务的最小、平均和 99 分位的执行时间，单位是毫秒 (ms)

oltp_point_select

select_random_points

oltp_read_only

oltp_write_only

oltp_read_write

oltp_update_index

oltp_update_non_index

7、结果分析

oltp_write_only 场景下，对比以前测试的 TIDB 2.1.8 版本的结果 (除了版本其它场景都相同) 如下：

从测试结果来看，TIDB 3.0.5 的 raft 改成多线程后相同测试场景下，业务的平均响应时间降低非常明显，同时 QPS 也明显增加，普遍在 30+%。

8、结论

升级到 TIDB 3.0.5 对写入的提升非常明显，并且 3.0.5 也是一个比较稳定的版本，我们经过线上各种场景灰度验证后，已将 50 多个集群升级到该版本，解决了长期被业务吐槽的写入延迟过大的问题，并且为了达到业务响应时间而增加的 TIKV 机器也可以节省下来，明显降低了业务的使用成本。