作者：蔡玮
中间件dble测试成员，主要负责dble的日常测试工作，热衷于探索发现，学习新技术。
本文来源：原创投稿
*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。
背景介绍
BenchmarkSQL 是一个支持众多关系型数据库的基准测试工具，通过使用 BenchmarkSQL 对数据库进行 TPC-C 标准测试，即模拟多种事务处理：新订单、支付操作、订单状态查询、发货、库存状态查询等，从而获得最终的压测值。相较于 Sysbench 的单一，它更能贴切的模拟出真实的应用场景，因此越来越多的客户在对数据库进行压测时，更多的选择使用 BenchmarkSQL 。
作为一款数据库中间件，dble 同样也是可以使用 BenchmarkSQL 进行压测的，但是压测压测过程中，往往如何调优，从而测得产品得最大压测值则是更值得关注的，本文将从可观测角度，绕开内部逻辑，介绍我们内部在使用 BenchmarkSQL 压测 dble 时的一些调优经验总结以及观测手法，以供大家参考。这种调优手段主要集中在配置以及 dble 内部线程数上。
配置建议
本文主要针对的是调优借鉴，在这里就不再过分的介绍 BenchmarkSQL 安装以及 dble 安装等过程，也将不再就数据准备以及压测步骤展开进行叙述。
但是有必要就一些必要配置信息做一些必要以及建议值的简要说明。
后端连接数
需要确保压测时，dble用户连接数 > 压测并发数
dble 中存储节点最大连接数 = 对应后端 MySQL 的最大连接数 >> (并发数 / 存储接节点数量)
日志级别
建议将 dble 的日志级别设置为 WARN ，设置的对应配置文件为 dble/conf/log4j2.xml
隔离级别
dble和后端数据库的隔离级别设置为RC隔离级别，如果是RR隔离级别会在压测过程中出现锁等待超时的报错，原因可参考历史公众号文章：https://mp.weixin.qq.com/s/-2I39hukyUb8qpzMmftfFA
关闭dble可能会影响性能的参数开关
建议关闭 dble 中一些可能会影响性能的参数开关，其他的开关如果非必要均可以关闭，如：useSqlStat=0，enableSlowLog=0
dble的配置
至于 dble 的配置信息，需要额外关注的是，在压测时需要将 config 以及 item 表设置为全局表，其他表全部设置为分片表，同时为了确保后端数据库压力的均匀分配，应当确保分片表的数据均匀分布在后端数据库上，这里建议采用求模算法，以便于达到目的
MySQL 的配置
至于 MySQL 的性能参数配置信息，需要根据机器配置自行调优，在这里不再赘述
观测手段
系统资源观测工具
在使用压测工具进行压测时，选择一款简单好用的系统观测工具有时候也是很重要的，以便于我们观测瓶颈所在并进行一些可尝试的调优。这里推荐使用 dstat 工具，其可以实时地看到所有系统资源，例如，CPU 使用情况、磁盘 IO 以及 网络 IO情况。
dstat 更可以将观测到的结果输入到 csv 文件，以便于后续绘图等分析。
以下为 dstat 的实时输出结果，详情可参考 https://linux.cn/article-3215-1.html
dble侧观测手段
这里提供两种dble侧可以使用的观测手法：
- 开启查询耗时统
需要在dble bootstrap.cnf中开启 useCostTimeStat=1，并重启dble生效，以下为观测样图：
DBLE 将查询分为了六个阶段：
1)开始梳理
2)完成解析
3)完成路由分配
4)从数据库回收结果
5)后置处理
6)反馈处理
我们只需要重点关注 WallTime.Avg ，其指代了每个阶段的平均耗时，这样我们可知道压力到底在中间件的哪一个阶段变慢。然后根据不同阶段的耗时异常，去调整 dble 内部的线程数或者排查后端mysql。详情可参考：https://actiontech.github.io/dble-docs-cn/2.Function/2.18_performance_observation.html
- 查看线程使用率
dble 内部提供了查看各类线程使用率的命令：show @@thread_used ，借助此命令可以在压测过程中查看各类线程的使用情况，然后进行相应的线程数量调整，以下为命令展示样图。
压测经验
在我们刚开始去使用 BenchmarkSQL 去压测 dble 时，同样也并不是很清楚各类线程数的大小对于性能的正负影响，都是在一步步的摸索中，才慢慢得到了初步的结论，在此给大家介绍一下相关的情况。
关于 dstat
由于 dstat 主要用于资源占用观测，所以在测试的过程中，作为辅助性工具使用一直打开，用于观察资源使用情况。并未作为调整的依据。
关于查询耗时统计
我们首先使用了 dble 内部的耗时统计功能【useCostTimeStat=1】，去测试不同阶段的耗时情况，然后根据 SQL 执行不同阶段的耗时情况调整线程数。但是测试时发现，调整了线程数并不能有效解决观测到的耗时异常情况，说明这些耗时异常情况并不适用于通过线程数上的调整去解决问题，这也是通过 BenchmarkSQL 压测 dble 时所发现的一问题之一，对此我们也有记录，并会持续的跟进调查。
关于 show 命令
由于依据查询耗时统计去调整 dble 的线程数量，并未起到良好的效果。所以，在压测过程中，管理端命令 show @@thread_used 观测线程使用情况，就成了我们调整线程数量的主要依据。
按照其他压测工具压测 dble 的经验，在压测之初我们也想着确保各类线程的使用率在80%以下，确保线程不那么繁忙，可是测试中发现，在调整各类线程数将各类线程使用率降至80%之后，有时得到了压测 tpmC 值反而不升反降了，猜想，难道是线程数量过多，频繁的线程切换影响性能，那反之又该如何？
所以下一步我们的方向，则是将dble内部的线程按照类型分为三类：
- 前后端IO线程：processors、backendProcessors
- 前后端业务处理线程：processorExecutor、backendProcessorExecutor
- 其他线程：complexExecutor、writeToBackendExecutor
参照 show @@thread_used 查询出来的线程使用率，按照不同类型的线程进行数量上的上下调整。
在调整的过程中我们发现，不同类型线程数量的上下调整，对于压测结果，效果是不一样的。经过多轮测试得到以下结论：
- 前后端 IO 线程 及 complexExecutor、writeToBackendExecutor的数量对于压测 tpmC 的值没有明显影响
- 对于tpmC值影响最大的为前后端业务处理线程数量，且前后端业务处理线程使用率与 tpmC的值正向相关，即前后端业务处理线程的线程使用率越高，tpmC 的值越高
- dble 所在机器的网络 IO 与 tpmC 的值正向相关，即网络 IO 越高，tpmC的值越高【通过观察 dstat 的结果而得】
- 前后端业务处理线程数量调整，对于 dble 所在机器的网络 IO 与前后端业务处理线程使用率影响一致，即前后端业务处理线程数量下调， 网络 IO 上升、线程使用率上升，且 tpmC 值越高
总结
通过以上的调整手段，在配置不变的情况下，基于 dble 3.20.10.0 版本，我们内部在压测时得到压测结果，dble 【后端挂有4个MySQL节点，1000数仓、1000线程并发】 ： MySQL【 250数仓，250线程并发】 = 2.8 ：1 左右。
当然，在理想情况下，两者的 tpmC 的值应该可以达到 4：1左右，可以看到，应该还是有可以提升的空间。除去必要的网络损耗，在其他 dble 内部可以优化的地方，我们的团队仍在努力尝试进行其他的优化，大家可以期待一下后续的版本表现。
至此，建议大家在使用 BenchmarkSQL 压测 dble ，使用可观测手段进行调优时，目前可主要针对前后端业务处理线程的数量进行调整（调低），调整的依据即为：
- 理应保持前后端业务处理线程的使用率维持在一个比较高的水平，建议在95%左右
- 通过dstat命令观测到dble所在机器的网络 IO 数值越高越好
此外，前后端 IO 线程数量和其他类型的线程数量可依据机器配置按照 dble 官方推荐值进行适配。另外需要注意的是，如果是多次进行压测，建议每次压测时都要将历史数据删除并重新进行数据准备，以免首次压测后造成数据上的污染，导致后续压测结果与首次压测结果偏差较大的问题。
