OceanBase 2.2 体验：用JMeter测试OceanBase性能
OceanBase 2.2 体验：用JMeter测试OceanBase性能
本文介绍使用JMeter测试OceanBase性能的方法。
这个方法适用于所有关系数据库(包括分布式的)。
测试方法。
在前文《分布式数据库选型测试(一)——测试需求》里已经就数据库性能对比测试的方法做过总结，这里再补充一些内容。
测试OceanBase集群性能的方法有很多，如sysbench、benchmarksql。不过如果想对比OceanBase数据库跟传统数据库、其他友商分布式数据库产品的性能差异，还需要找到一个能适用彼此的测试方案。sysbench的功能太弱，且只有0.4 支持ORACLE，不同版本的sql还不完全一样。benchmarksql倒是很合适，有一定业务模型，且标准简单容易统一比较。不过如果客户还想测试一点点业务sql，那就只能自己写程序了。如果嫌写程序麻烦，还有个简单的办法就是使用JMeter。
数据库驱动
使用JMeter测试OceanBase性能的时候也需要加载OceanBase的Java驱动。文件可以从官网的下载文件中获取，或者从这个途径：
https://github.com/obpilot/benchmarksql-5.0/blob/master/lib/oracle/oceanbase-client-1.0.9.jar
下载的oceanbase-client-1.0.9.jar需要放到Jmeter的lib文件夹夹中。
业务场景定义
建表语句
请在OB-ORACLE租户下业务账户执行下面SQL 。
$obclient -h127.1 -utpcc@obbmsql#obdemo -P2883 -p123456 -c -A tpcc
CREATE TABLE account(id number NOT NULL PRIMARY KEY
, name varchar2(50) NOT NULL UNIQUE
, value number NOT NULL
, gmt_create date DEFAULT sysdate NOT NULL
, gmt_modified date DEFAULT sysdate NOT NULL );
CREATE SEQUENCE seq_account START WITH 1 INCREMENT BY 1 nocycle;
delimiter /
CREATE OR REPLACE TRIGGER trg_before_ins_account
BEFORE INSERT
ON account
FOR EACH ROW
BEGIN
select seq_account.nextval INTO :NEW.id FROM DUAL ;
END;
/
delimiter ;
示例中的触发器和序列不是必须的。这只是一种常用的用法。ORACLE租户的序列能保证值递增(序列属性是NOCYCLE),但不一定保证连续(事务回滚时会浪费序列值)。这里的测试案例期望产生的测试数据是连续的。
造连续自增的测试数据的方法就不说了。
场景SQL
此次测试模拟一个分布式事务，SQL类似如下：
-- session A
begin ;
select value from account where id = 174 for update ;
update account set value = value - 7 , gmt_modified = sysdate where id = 174 ;
update account set value = value + 7 , gmt_modified = sysdate where id = 165 ;
-- commit or rollback;
commit;
新建JMeter测试计划
JMeter能在命令行下运行，也可以以图形界面运行。这里我简单点直接用图形界面这种方式。
新建测试计划
测试计划属性
新建 Thread-Group
这里有很多跟多线程运行有关的JMeter参数，具体说明可以查看JMeter官网文档。
注意这里的Number of Threads是指压测的客户端线程数。
JDBC连接属性
这里面属性很多，都是一个连接池常具备的参数。有兴趣的可以看看网上关于Java连接池配置的经验。
这里面也有几个参数强调一下：
Max Number of Connections：这个指连接池里最多多少个连接。如果压测线程数远高于这个值，那么压测线程可能会需要等待这个连接池创建或返还数据库连接(即到OceanBase的连接)给它。如果等不到可能会报错。在这个环节，客户端压测线程拿不到连接，不一定跟OceanBase数据库有直接关系。在Java应用里面也同理。Transaction Isolation：这个是数据库连接使用的事务隔离级别，OceanBase支持两种事务隔离级别：读已提交(Read-Committed)和序列化(Serializable)。前者很常见容易理解，后者是ORACLE特有隔离级别，OceanBase也兼容了。有兴趣的可以看看《OceanBase事务引擎特性和应用实践分享》。理解序列化隔离级别的特点和场景可以加深自己对数据库事务的理解。Test While Idle：这个是连接探活(keepalive)设置。这个设置对应用却很优必要。有时候应用会说数据库连接报错说在一个关闭的连接上执行SQL报错，这个就是因为连接池中的数据库连接因为其他原因已断开了。所以，数据库连接池通常都需要探活机制。这里由于是压测场景基本无闲置连接，所以可以设置为False。Database URL：数据库连接URL格式，直接类似填写jdbc:oceanbase://11.***.***.5:2883/tpcc。JDBC Driver Class：数据库驱动中的Main类名，这个要按OceanBase格式填写，com.alipay.oceanbase.obproxy.mysql.jdbc.Driver。Username：用户格式，OceanBase的用户名格式比较特别，是租户里用户名@租户名#集群名或集群名:租户名:租户里用户名。如tpcc@obbmsql#obdemo
事务参数(变量)
在这个测试里，有三个变量：账户A，账户B，转账金额，所以需要设置参数
账户参数和金额采取随机数，随机数的值不要超出测试数据实际范围。
事务控制器
这里面是维护每个事务的逻辑。事务由一组JDBC请求组成。
开启事务
选择 Autocommit(false)，开启显式事务。
查询账户A的余额
这里查询账户A的记录会同时锁住这笔记录，即常用的悲观锁技术。 这一步看测试需要，不是必需的。
select value from account where id = ? for update ;
注意所有参数都使用Prepared Statement，以下同。
这一步后面按业务设计应该检查一下返回值是否大于要转账的值，如果不满足就是“转账余额不足”。这里我没有去研究JMeter如果根据查询返回值进行逻辑判断。有兴趣的朋友可以自己研究。
扣减账户A的余额
SQL很简单。
update account set value = value - ? , gmt_modified = sysdate where id = ? ;
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Mm5Q9slr-1584840402750)(media/15764843389279/15847853936218.jpg)]
多个绑定参数使用逗号(，)分隔。
然后要新增一个Post处理逻辑，获取更新返回值
增加账户B的余额
SQL很简单。
update account set value = value + ? , gmt_modified = sysdate where id = ? ;
同样，需要增加一个Post处理器
判断逻辑——成功流程
如果上面两笔账户的更新成功，则提交事务。
新增判断控制 IF
新增动作
判断逻辑——失败流程
如果上面两笔账户的更新有一笔失败，则回滚事务。
新增判断控制 IF
新增动作
查看结果细节
可以查看成功、失败的结果
查看汇总报告
数据库SQL审计
在业务租户下的sys用户下，利用OceanBase的SQL审计功能可以查看JMeter发出的测试SQL细节。在这个里面可以看到SQL的执行细节(错误码、耗时、等待事件之类)，对分析性能结果非常有帮助。
select /*+ read_consistency(weak) query_timeout(1000000000) */ TO_CHAR(request_time / (1000000 * 60 * 60 * 24) + TO_DATE('1970-01-01 08:00:00', 'YYYY-MM-DD HH:MI:SS'), 'HH24:MI:SS') request_time_, sid ,query_sql, affected_rows,return_rows, ret_code, event, state, plan_type,is_hit_plan, elapsed_time, execute_time, queue_time, decode_time, get_plan_time, block_cache_hit, bloom_filter_cache_Hit, block_index_cache_hit, disk_reads,retry_cnt,table_scan, memstore_read_row_count, ssstore_read_row_count, round(request_memory_used/1024/1024) req_mem_mb
from gv$sql_audit
where 1=1 AND user_name='TPCC' AND DB_NAME='TPCC' AND query_sql NOT LIKE '%SHOW%'
order by request_time desc ;
其他
这个测试场景和方法虽然简单，但实际测试中可能会遇到一些问题。分析这些问题也可以了解OceanBase的特点。
如果测试数据记录数很少时，使用一定的并发压测，很容易就出现锁等待和阻塞现象。这个时候看报告会发现update的延时会增加，甚至rollback的事件会增加。如果默认的锁等待时间和事务超时时间很长，可能发现update都堵在那里，会有很多死锁事件。详情请参见《从ORACLE/MySQL到OceanBase：数据库超时机制》。
参考
- OceanBase 2.2 安装部署问题解答
- 分布式数据库选型测试(一)——测试需求
- OceanBase 2.x体验：用BenchmarkSQL跑TPC-C
- 从ORACLE/MySQL到OceanBase：数据库超时机制