tpcc使用说明
说明：文章内容起源于网络并结合自己的实验而得；但参考的文章地址当时没记录下来，如果发现有侵权问题，请留言。
一、介绍
压力测试是指在MySQL上线前，需要进行大量的压力测试，从而达到交付的标准。压力测试不仅可以测试MySQL服务的稳定性，还可以测试出MySQL和系统的瓶颈。
TPCC测试：Transaction Processing Performance Council，要熟练使用TPC是一系列事务处理和数据库基准测试的规范。其中TPC-C是针对OLTP的基准测试模型，一方面可以衡量数据库的性能，另一方面可以衡量硬件性价比，也是广泛应用并关注的一种测试模型。
TPC-C测试模型给基准测试提供了一种统一的测试标准，并非实际应用系统中的真实测试结果，但通过测试结果，可以大体观察出MySQL数据库服务稳定性、性能以及系统性能等一系列问题。TPC-C仅仅是一个测试模型，而在实际测试中，需要参考和使用一些测试工具，对系统和MySQL数据库进行压力测试、稳定性测试。
TPC-C模型是以一个在线零售业为例，设计的一种模型，具体架构图参考
tpcc测试库数据比例图
和
tpcc测试库数据表关系图
二、编译安装
1、下载地址
https://github.com/Percona-Lab/tpcc-mysql
2、修改程序，以实现对MGR的支持
如果是测试MGR模式，则需要手动修改与history表相关内容，因为该表没有主键，而MGR却要求表必须有主键：否则，可跳过。
# unzip tpcc-mysql-master.zip
1）在建表语句中，新增主键列：
# vim tpcc-mysql-master/create_table.sql
大约在62行处为history表的建表语句；在其中添加建立主键id的语句：
create table history ( id bigint not null auto_increment, -- 新增id自增列 h_c_id int, h_c_d_id tinyint, h_c_w_id smallint, h_d_id tinyint, h_w_id smallint, h_date datetime, h_amount decimal(6,2), h_data varchar(24), PRIMARY KEY (id) -- 新增主键(注意与上一行的逗号分隔) ) Engine=InnoDB;
2）修改INSERT语句
# vim tpcc-mysql-master/src/load.c
大约在234行处为history表的INSERT语句，修改为如下内容:
"INSERT INTO history values(null,?,?,?,?,?,?,?,?)", 48) ) goto Error_SqlCall_close;
修改说明:
对主键列id在插入时新增null值，以便id自增；
将记录原INSERT语句字符数校验的数字从43改为48；
以上2不修改完成后可以继续，执行编译了。
3、解压编译
# cd tpcc-mysql-master/src/ # make (没有make install)
执行成功后，在tpcc-mysql-master解压目录下生成了tpcc_load和tpcc_start命令
4、查看libmysqlclient.so.xx库文件
备注:
当前的版本的tpcc必须使用libmysqlclient.so.xx版本的mysql库文件。
mysql5.6为libmysqlclient.so.18
mysql5.7为libmysqlclient.so.20
设置方式有如下2种：
方式1：mysql5.7的libmysqlclient.so.20
# cat /etc/ld.so.conf include ld.so.conf.d/*.conf # echo "/usr/local/mysql-5.7.24/lib/" >> /etc/ld.so.conf # cat /etc/ld.so.conf include ld.so.conf.d/*.conf /usr/local/mysql-5.7.24/lib/ # /sbin/ldconfig -v
方式2：mysql5.6的libmysqlclient.so.18
# ls -l /usr/lib64/libmysqlclient.so*
如果不存在，则后面执行tpcc_load和tpcc_start命令时会报错。
将Mysql程序目录下lib目录中的libmysqlclient.so.18拷贝放入系统库并赋权限(也可在环境变量的PATH中指定该库文件地址)：
# mv libmysqlclient.so.18 /usr/lib64/ # chmod 777 /usr/lib64/libmysqlclient.so.18
在测试完成后，删除该库文件
# rm /usr/lib64/libmysqlclient.so.18
三、加载测试数据
进入工作目录(解压后的目录)
# cd tpcc-mysql-master
1、在目标MySQL上创建测试数据库
mysqladmin -uroot -p -S /data/s1/mysql.sock create tpcc1000
2、创建表
mysql -uroot -p -S /data/s1/mysql.sock tpcc1000 < create_table.sql
tpcc创建了九张测试表：
客 户：customer 表
地 区：district 表
商 品：item 表
历史订单：history 表
新订单 ：new_orders 表
订单状态：order_line 表
订 单：orders 表
库存状态：stock 表
仓 库：warehouse 表
tpcc-mysql的业务逻辑及其相关的几个表作用如下：
New-Order==>新订单，一次完整的订单事务，几乎涉及到全部表
Payment ==>支付，主要对应 orders、history 表
Order-Status==>订单状态，主要对应 orders、order_line 表
Delivery ==>发货，主要对应 order_line 表
Stock-Level==>库存，主要对应 stock 表
3、对表添加外键
mysql -uroot -p -S /data/s1/mysql.sock tpcc1000 < add_fkey_idx.sql
4、载入测试数据
# ./tpcc_load --help Usage: tpcc_load -h server_host -P port -d database_name -u mysql_user -p mysql_password -w warehouses -l part -m min_wh -n max_wh * [part]: 1=ITEMS 2=WAREHOUSE 3=CUSTOMER 4=ORDERS
例如：创建5个仓库，加载全部表的测试数据
# ./tpcc_load -h 127.0.0.1 -P 3306 -d tpcc1000 -u root -p ‘123456‘ -w 5
备注:
1）这个过程有点慢 ，1个warehouse对应10个地区，1地区对应3000的用户，10个仓库刚导入进去的大小约为1G；
2）仓数可根据需要来设置，总结网上资料所说，设置40-100个是对CPU的测试，400-1000个是对IO的测试，40以下无论事务多少，锁竞争情况也不太容易发生；
3）真实测试场景中，仓库数一般不建议少于100个，视服务器硬件配置而定，如果是配备了SSD或者PCIE SSD这种高IOPS设备的话，建议最少不低于1000个。
如果要并行加载测试数据，可以使用load.sh脚本。
四、执行测试
1、非MGR多主模式压测
./tpcc_start -h127.0.0.1 -P 3306 -dtpcc1000 -uroot -p ‘123456‘ -w 5 -c 32 -r 10 -l 30 -i 10 -f tpcc_mysql.log -t tpcc_mysql.rtx
-h：测试主机
-d：测试的数据库
-u：测试的用户
-p：测试用户的密码
-w：测试的warehouse数
-c：测试的连接线程数
-r：预热时间，warmup_time，以秒为单位，默认是10秒，目的是为了将数据加载到内存
-l：测试时间，默认为20秒
-i：report_interval指定生成报告的间隔时间
-f：report_file将测试中各项操作的记录输出到指定文件内保存
-t：trx_file输出更详细的操作信息到指定文件内保存
备注：
真实测试场景中，建议预热时间不小于5分钟，持续压测时长不小于30分钟，否则测试数据可能不具参考意义。
2、MGR多主模式压测
由于MGR在对大事务支持和事务冲突检测上的限制和不足，导致对MGR直接并行压测是不可能的。Oracle官方的Multi-Primary Mode测试是在每个结点上，
对不同的测试库进行压测，即这样可以避免了工具无法并行压测的问题，同时，这样也减少了冲突的可能性。切记，Multi-Primary Mode一定要避免热点数据冲突的场景。
例如MGR集群中有3个节点，分别为A、B、C；那么，压测时需要建立至少3个库；这样每个tpcc压测都使用1个线程来测试一个库，并且同时启动多个tpcc来测试。
可以这样测试：
A节点：
./tpcc_start -h188.188.0.68 -P3306 -uroot -p ‘123456‘ -d tpcc1 -w 5 -c 1 -r 10 -l 30 -i 10 -f tpcc_mysql.log -t tpcc_mysql.rtx .....
B节点：
./tpcc_start -h188.188.0.69 -P3306 -uroot -p ‘123456‘ -d tpcc2 -w 5 -c 1 -r 10 -l 30 -i 10 -f tpcc_mysql.log -t tpcc_mysql.rtx .....
C节点：
./tpcc_start -h188.188.0.70 -P3306 -uroot -p ‘123456‘ -d tpcc3 -w 5 -c 1 -r 10 -l 30 -i 10 -f tpcc_mysql.log -t tpcc_mysql.rtx .....
不过对Multi-Primary Mode压测并不会有一个很好的结果，因为热点太过集中，会导致提交失败很多，或许反而会导致了性能的下降。
五、结果分析
[ tpcc-mysql-master]# ./tpcc_start -h127.0.0.1 -P24801 -dtpcc1000 -uroot -p ‘‘ -w 5 -c 32 -r 10 -l 30 -i 10 -f tpcc_mysql.log -t tpcc_mysql.rtx
***************************************
*** ###easy### TPC-C Load Generator ***
***************************************
option h with value ‘127.0.0.1‘
option P with value ‘24801‘
option d with value ‘tpcc1000‘
option u with value ‘root‘
option p with value ‘‘
option w with value ‘5‘
option c with value ‘32‘
option r with value ‘10‘
option l with value ‘30‘
option i with value ‘10‘
option f with value ‘tpcc_mysql.log‘
option t with value ‘tpcc_mysql.rtx‘
<Parameters>
[server]: 127.0.0.1
[port]: 24801
[DBname]: tpcc1000
[user]: root
[pass]:
[warehouse]: 5
[connection]: 32
[rampup]: 10 (sec.)
[measure]: 30 (sec.)
RAMP-UP TIME.(10 sec.)
MEASURING START. -- 预热结束，开始进行压测
-- 设置的每10秒钟输出一次压测数据
10, trx: 1500, 95%: 204.109, 99%: 430.483, max_rt: 666.515, 1502|936.479, 150|225.372, 151|995.094, 151|650.192
20, trx: 1349, 95%: 191.559, 99%: 458.275, max_rt: 659.284, 1342|842.605, 134|191.606, 136|981.992, 135|522.363
30, trx: 1211, 95%: 209.746, 99%: 519.825, max_rt: 766.855, 1213|987.708, 122|142.544, 121|1085.795, 121|386.247
说明:分为6项，依次为操作时间(秒)、创建订单、订单支付、查询订单状态、物流发货以及查询库存仓储
10, ==>测试进行的时间(秒)
trx: 1500, ==>在给定间隔期间执行的新订单交易数；它基本上是每个间隔内的吞吐量，该值越大越好。
95%: 204.109,==>每个给定间隔的95％的新订单交易响应时间，这里是204.109秒。
99%: 430.483,==>每个给定间隔的99％的新订单交易响应时间，这里是430.483秒。
max_rt: 666.515,==>每个给定间隔的新订单交易的最大响应时间，这里是666.515秒。
1502|936.479, 150|225.372, 151|995.094, 151|650.192==>是其他类型事务的吞吐量和最大响应时间，可以忽略。(订单支付、查询订单状态、物流发货以及查询库存仓储)
STOPPING THREADS................................ -- 压测结束
<Raw Results>
[0] sc:0 lt:4060 rt:0 fl:0 avg_rt: 86.8 (5)
[1] sc:1 lt:4056 rt:0 fl:0 avg_rt: 167.6 (5)
[2] sc:345 lt:61 rt:0 fl:0 avg_rt: 8.6 (5)
[3] sc:0 lt:408 rt:0 fl:0 avg_rt: 449.4 (80)
[4] sc:15 lt:392 rt:0 fl:0 avg_rt: 132.6 (20)
in 30 sec.
-- 第一次结果统计说明
[0] ==>New-Order，新订单业务成功(success,简写sc)次数，延迟(late,简写lt)次数，重试(retry,简写rt)次数，失败(failure,简写fl)次数；一次完整的订单事务，几乎涉及到全部表。
[1] ==>Payment，支付业务统计，其他同上，主要对应 orders、history 表；
[2] ==>Order-Status，订单状态统计，其他同上，主要对应 orders、order_line 表；
[3] ==>Delivery，发货业务统计，其他同上，主要对应 order_line 表；
[4] ==>Stock-Level，库存业务统计，其他同上，主要对应 stock 表；
<Raw Results2(sum ver.)>
[0] sc:0 lt:4060 rt:0 fl:0
[1] sc:1 lt:4060 rt:0 fl:0
[2] sc:345 lt:61 rt:0 fl:0
[3] sc:0 lt:408 rt:0 fl:0
[4] sc:15 lt:392 rt:0 fl:0
<Constraint Check> (all must be [OK]) -- 下面所有业务逻辑结果都必须为 OK 才行
[transaction percentage]
Payment: 43.45% (>=43.0%) [OK] -- 支付成功次数(上述统计结果中 sc + lt)必须大于43.0%，否则结果为NG，而不是OK
Order-Status: 4.35% (>= 4.0%) [OK] -- 订单状态，其他同上
Delivery: 4.37% (>= 4.0%) [OK] -- 发货，其他同上
Stock-Level: 4.36% (>= 4.0%) [OK] -- 库存，其他同上
[response time (at least 90% passed)] -- 响应耗时指标必须超过90%通过才行
New-Order: 0.00% [NG] * -- 下面几个响应耗时指标全部 未 通过
Payment: 0.02% [NG] *
Order-Status: 84.98% [NG] *
Delivery: 0.00% [NG] *
Stock-Level: 3.69% [NG] *
<TpmC>
8120.000 TpmC -- TpmC结果值（每分钟事务数，该值是第一次统计结果中的新订单事务数除以总耗时分钟数）完毕！