开发者学堂课程【PolarDB-X 开源分布式数据库进阶课程 ：PolarDB-X 进行 TP 负载测试（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1202/detail/18329
PolarDB-X 进行 TP 负载测试
三、Benchmark Boot 介绍
主导了一站式兼容性，易用性，可视化一站式就是内置好了bench mark tpcc这三样精准测试工具，兼容性就是体现在它可以在不同的系统平台安装部署应用性能，易用性则体现在整个压测流程都是白屏化操作，最终的测试结果也可以通过表格，折线图，柱状图等形式来进行可视化展示，相关的安装使用文档在开源官网文档的生态工具一栏也是可以找到，这里点击链接可以跳转过去看到这里面目录包含了工具介绍功能的路线图，还有部署启动的教程，使用方法以及 change log 更新日志，可以看到最近一次更新是在11月16号的1点3.1版本。
正如刚刚所说的，它的部署安装步骤步骤非常简单，他既提供了一件安装命令，又提供了都可镜像省区处理依赖安装问题的麻烦，当然他也有一些前期准备的要求，在关于官网，也可以看得到他要求压缩机需要有不低于4c 8G 的配置，这是因为压缩机规格太低，容易成为性能的瓶颈，同时还需要一台有浏览器的机器。这里准备了两台不同 CPU 架构，不同操作系统的 ecs 给大家演示一下一键部署安装的流程，通过arc命令我们可以看得到左边这台是X86架构，而右边这台则是 arm 架构，那么左边这台是乌邦图的操作系统，右边这台是 os 的操作系统，两台机器的 CPU 都是八核，内存都是32G。可以看到现在是在 -root 目录下，当前目录下是没有安装任何东西，我们来官网看一下这个一键安装命令直接把它复制到命令行这里来，按回车，它会自动下载最新的这个 bench boots 安装包，然后自动进行编译安装这里面也列举了几种可能会失败的情况，以及需要注意的一些事项，对于 Windows 操作系统，或者其他安装失败的特殊场景也可以使用 docker 容器，来部署 bench mark boots。
省去了处理依赖安装失败的这个问题的麻烦，可以看到现在这个进程已经开始了，有两个 boot 的进程，那么我们可以通过 curl 命令去看看这个服务是否生效。可以看到这个端口都是有响应的，也可以通过浏览器访问对应IP的4121端口来看看压测平台的首页，是否有展示，
这个就是我们压测平台的首页，待会我们也会进行实操展示，后续对 polarDB-dx 数据库的性能测试都是白屏化的操作来实现，主要包括以下这几个步骤：压测目标数据库的连接配置，我们在数据库连接面板中填入 Polar- dbx 的集群 IP 端口用户名密码之后输入 bench 库名，tpcc 库名，然后选择对应 polarDB-x 的监控模式和 ioo 模式。
下一步则是自动参数调优，如果想要测 Polardb-x 的极限性能，可以尝试使用一键调优功能，每个工程选项会发送相应的 set global 语句去调整性能相关的参数，这一点我们也会在接下来的演示中仔细讲解，当然这一步是可选的导入压测数据，我们要设置数据表，数据量比较大小，表的数量比较大小，还有导入的并发数导入完毕后，我们可以进行数据校验运行压缩。
运行压测步骤则是先设置好刚才导入的表数量，表大小，选择负载类型和对应的并发数运行时间，然后开始压测在最后的压测结果汇总中可以看到 PS 曲线，平均 PS tps，平均 rt 等历史任务信息。
Tpcc 的流程也是完全一致的，首先根据压缩机规格和参数来选择合适的并发数导入，接下来停入压测并发数和运行时间。
开始压测最后的结果汇总中可以记录历史任务信息，也可以对比查看实时的 tpmc 曲线,我们会一边实际的操作，一边来进行讲解。
这里我们再通过 polar D-X 部署 cnD 的 tx 集群，可以通过 p3pd list 命令来查看一下配置文件，从配置文件里面可以看到三个 leader 节点均匀的分布在三台14s上，这里，我们来以82节点为例，现在这边的命令行是82节点，这台dnan 节点上面的容器可以看到它分别有三个容器，又由于我们是通过 polarDB-x 进行部署的，它是需要额外的负载均衡组件，比如 LV sae 或者 f5的来对外提供统一的集群接入地址，这里已经通过 lot 服务进行 cn 计算节点的负载均衡配置，已经备好了这个连接串信息，因为部署后会首先给我们三个 cn 节点的连接信息，再通过一个额外的服务来配置一个负载均衡。连进去执行一下，就看到已经预先创建好了两个 bench 的测试库和一个 tb。
下面我将演示如何使用 benchmark 性能测试平台来进行测试，通过命令可以看得到我现在网络延迟大概在0.1毫秒左右，打开对应的浏览器网页，我们可以看到在首页部分可以看到当前的部署版本3.1，点击版本更新日志则会跳转到官网文档的签字在下面，在首页的下面也展示了压测流程配置，数据库连接导入压缩数据，调整实力参数，开始压测结果分析，这几个步骤我们之前也是讲过的，那么我们首先来配置一下数据库连接，建仓是指建数据库的话呢，我们这些数据库既可以提前通过命令行的方式可以对他来建好，也可以通过在 book 平台来进行一个自动的创建，这后面有时间的话也是可以演示的。
那么现在把刚刚的这个连接串先给填入进来，主机IP还有端口号用户名密码那么点击提交后，平台会自动校验数据库的联通性，我现在演示的这些步骤在文档中也有详细的描述，大家后续在云起实验室里面体验的时候，可以直接参照教程或者文档，那么再往下看，在一键调用这个部分分为 aptp 模式调优与 ap 模式。常用的调用这里要注意大部分的参数都是 bbx 独有的，比如第一个 circle circle 审计日志 CPU profile，还有后台统计信息采集，全局思索检测事务日志信息和私有协议并发上限以及 SQL 语句的 summary 统计，还有相关的 adaptive hush desk 和 table open cash，如果大家是在做云起实验室的时候，这些参数是不太建议一起调整的，因为有些参数是基于较大的规格提前定好的，这里尽量是高于4c 8G乘2以上的实力规格来开启，比如这个 open 或者是并发上限的，它可能只适用于大于这个规格的实力，我们可以点击提交，它就会自动发送以上这些 global 语句是我们的数据库实例里面进行一个调优。
下面我们来尝试进行 bench 压测：
由于刚刚并没有填入 bench 数据库，需要手动填入我们已经创建好的数据库，对于已经创建好的数据库，be test选择自动判断监控模式，它就会自动的判断数据库的监控模式是 o，要创建一个在这里创建一个新的数据库，比如说建一个叫 test 1 的，那么这个时候就不能选择自动判断了，因为自动判断它是以当前现有的数据库来判断，所以它会报错 unknown database。所以如果要创的话，就需要手动去选择监控模式，平台才会为我们创建，还有一种模式是MySQL 模式，也就是说我们这个编程的平台当时也是可以对金融 soo 的数据库来进行压测的，只是说对于测试的时候，它会自动的去潜入跟分布式相关的一些建表参数，切回刚刚的 test这个数据库，
因为我们为了节省时间，我们这里已经提前导入好了 bench 数据，点击教育数据，数据完整，可以看到显示了bench 一共有四张表，每张表是100万的一数据量，所以我们接下来来运行一下 bench。看一下填入表数量，单表
大小和要跑的并发数，这里先来测试一个50并发的检查。因为 bench 其实是支持很多别的参数的，这里就介绍了一些常用的额外的参数比如 size，决定了 between 查询的范围大小，还有 prepare statement mode 是否开启协议skip transaction，还有 rt 分布的直方图以及忽略的报错类型，这里默认的忽略报错类型是会忽略所有的报错，在任务描述这里，填入任意一段有意义的描述，比如检查并发这一项是选填，
但是在后面的历史任务筛选中，可能填入的话，就是可以做一个筛选的条件，提交一下测试任务，然后可以来看一下实时的这个结果，这个实时结果其实就是命令行输出的一个转发过来的实时结果，实时结果里面包含了当前的并发数50实施的这个 PS with rice 的数量，还有95分位的一个延迟，这里单位是毫秒，也就是0.6毫秒，然后每秒的错误是0，还有重连次数是0。
那么如果现在还是不支持同一个 benchmark boots 上同时发起多项测试，所以此时他是会显示 bench 正在运行的，没有办法再提交一次任务，然后现在差不多跑了一分钟后，现在已经跑完了，我们可以来点击压测结果这里看一下刚刚跑的信息，也就是7:25的这个信息，我们可以点击这次任务来查看这个历史任务的，可以看到我们实际执行的是一条 bench 的一个命令，然后把我们刚刚的一些填入的参数给填写到了这个命令脚本中，可以实时看到这个实时的这个 q PS 数据可以看到它的波动曲线。
那么我们再来跑一个100并发的检查测试，这里可以直接点击填充上次运行参数，然后把并发数改成100，有相应的任务描述也改一下交任务，那么在这里运行压缩的时候，我们再回过头来讲一下，我们在压缩数据库的时候，一般会关注什么性能指标以及每个指标它代表了什么含义。
