数据库性能测试之tpcc-mysql压力测试
在上一篇博客中使用了sysbench基准测试，是对单张表进行的读写测试，由于不涉及表连接、外键约束、索引等操作，所以体现的是硬件性能，如果相要知道数据库集群在真实业务中的实际性能，那么需要压力测试。本篇博客讲解tpcc-mysql压力测试。
1. tpcc-mysql简介
tpcc-mysql是percona基于tpcc规范衍生出来的产品，专门用于mysql压力测试 。
tpcc是一种测试标准，明确规定了数据模型和检测是指标，而且检测的标准对数据库集群来说很苛刻，tpcc-mysql的测试库能覆盖大多数的业务场景，测试的结果也能反映出真实业务中数据库的实际性能。
1.1 tpcc数据模型
tpcc测试用到的数据模型是一个大型的商品批发销售公司，有若干分布在不同区域的仓库，每个仓库有10万种商品，每个仓库负责10个销售点，每个销售点有3000个客户，每个客户中的订单中有10个商品，另外有百分之1的订单商品在直属仓库中没有货，需要其他的仓库调拨
1.2 tpcc测试问题
tpcc的检测标准是针对单节点的mysql数据库，对sql的执行时间有严格的规定，我们要测试的pxc集群是以牺牲插入速度为代价换取的同步强一致性，假如tpcc要执行一个insert语句不能超过100ms，但是pxc集群只是写入速度慢，插入执行了300ms。这个检测点就没有通过，所以拿tpcc测试pxc集群不太适合，检测的标准太苛刻了一些，但是因为数据库集群在真实业务下实际的读写性能，每秒钟能执行多少次读操作，多少次写操作。至于由于插入速度慢测试报告中测试没有通过，可以不予理会。
1.3 tpcc测试方案
我们还是以haproxy+三个mysql节点的pxc集群来进行测试，haproxy+三个mysql节点的pxc集群如何搭建看博主往期博客。
2. 准备工作
2.1 关闭所有pxc节点
拿个节点用哪个命令，不在本篇博客中讲解，不熟悉的请看往期博客
systemctl stop [email protected]
service mysql stop
2.2 修改my.cnf文件
把pxc_strict_mode的值改成DISABLED
原来默认的参数值是不允许我们执行不符合规范的操作，比如创建出没有主键的数据表，tpcc数据库脚本里边有一个表没有主键，所以为了tpcc测试能进行下去我们要修改pxc_strict_mode的值
vi /etc/my.cnf
修改完my.cnf文件之后再重新启动pxc集群
2.3 安装环境包
yum install -y gcc
yum install -y mysql-devel
2.4 安装tpcc-mysql
下载压缩包
https://codeload.github.com/Percona-Lab/tpcc-mysql/zip/master
解压之后上传到测试服务器，上传到/home目录下
进入src目录，再使用make命令编译
cd src
make
2.5 创建测试库
到pxc集群的节点上创建数据库tpcc，我们在haproxy的节点上创建，那么pxc集群的mysql库也会自动同步
2.6 创建测试表和索引约束
我们进入安装tpcc-mysql的目录，查看tpcc的sql文件
ls *.sql
create_table.sql 是创建表的sql文件
add_fkey_idx.sql是索引等约束文件
将create_table.sql文件和add_fkey_idx.sql文件拿到navicat运行sql文件。
执行完sql文件创建了以下表。
2.7 准备测试数据
./tpcc_load -h 192.168.1.27 -d tpcc -u admin -p Abc_123456 -w 1
-h 192.168.1.27 数据库ip地址
-d tpcc 数据库名字
-u admin 用户名
-p Abc_123456 密码
-w 1 仓库数量，由于数量庞大，插入时间较长，所以这里使用1个仓库数量，如果使用多个仓库，耗时很长。
2.8 执行测试
./tpcc_start -h 192.168.1.27 -d tpcc -u admin -p Abc_123456 -w 1 -c 5 -r 300 -l 600 - >tpcc-outpit.log
-h 192.168.1.27 数据库ip地址
-d tpcc 数据库名字
-u admin 用户名
-p Abc_123456 密码
-w 1 仓库数量
-c 5 并发线程数
-r 300 数据库预热时间 单位秒
-l 600 测试时间 单位秒
— >tpcc-outpit.log 测试结果输出到文件
为了真实性可以将-r 和-l时间设置长一些，比如预热1个小时，测试24小时
查看日志日志出现了大量的死锁异常，执行压力测试的时候，事务执行的时间太久，没有及时提交事务，于是出现了锁冲突。让pxc集群的锁冲突降到最低，将并发的线程数改为1
./tpcc_start -h 192.168.1.27 -d tpcc -u admin -p Abc_123456 -w 1 -c 1 -r 300 -l 600 - >tpcc-outpit.log
2.8 测试报告分析
我们打开tpcc-ouppit.log文件，画的红色的框是最终结果
sc: 成功执行的次数
lt: 超时执行的次数
rt: 重试执行的次数
fl: 失败执行的次数
tpcc关注这4种测试的结果
第一行是新订单执行的测试结果，tpcc在规定时间内成功执行了0条记录，由于tpcc测试指标是非常苛刻的，你虽然执行了操作，但是执行时间没有达到tpcc的要求，所以不能算为执行成功，只能算做是超时执行。pxc集群是以牺牲速度为代价换取数据同步的强一致性。虽热增删改成都能执行，但是达不到tpcc的指标。rt(重试执行的次数)和fl(失败执行的次数)是0次。
第二行是支付业务的测试结果。成功执行了0次，超时执行了5993次，重试执行0次，失败0次
第三行是订单状态的测试结果。成功执行了451次，超时执行了149次，重试执行0次，失败0次
第四行是发货业务的测试结果。成功执行了0次，超时执行了599次，重试执行0次，失败0次
第五行是库存业务的测试结果。成功执行了0次，超时执行了601次，重试执行0次，失败0次
尽管达不到tpcc的测试指标，但是没有失败执行的。以上是各种业务下的增删改查操作。
下边是事务的一些操作。测试报告是通过了
在下边是关于响应时间的一个测试，NG代表没有通过，OK代表的是测试通过。用tpcc测试pxc集群有些不合理，tpcc测试是按照单节点mysql读写速度和响应时间来制定的指标。所以pxc集群很难能达到tpcc的指标，所以这里很多响应时间的指标都是NG没通过的。
再下边的TpmC是，每分钟pxc集群执行的事务数量。