环境
- 环境搭建参考之前写过的文章CentOS7 安装 Gauss DB 200 单节点
| server端说明 | 描述 |
|---|---|
| 服务器 | 华为泰山 2280 v2 【CPU*96 内存*128G 硬盘*2.2T（SAS）】 |
| 操作系统 | Cent OS 7.6 aarch64 |
| 数据库版本 | GaussDB_200_6.5.1_RHEL_ARM64 |
| cline说明 | 描述 |
|---|---|
| 测试机 | PC【CPU*8 内存*16G 硬盘*512G（ssd）】 |
| 操作系统 | win10 |
| 测试工具 | apache-jmeter-5.2.1 |
| 测试工具 | JDK1.8 |
场景 - 单条插入 (OLTP)
背景
数据库的最根本的作用是保存数据，数据落盘的效率是衡量一个数据库性能的最基本的指标。
设计
1000W行数据，100个并发连接在10秒内连接，连续插入。
准备
- 创建测试表
CREATE TABLE t_test1 (
id serial,
info text DEFAULT 'sfsluiejldksjfslaueijflsdjflsjfleifeiolfjsl'::text,
state integer DEFAULT 0,
crt_time timestamp without time zone DEFAULT now(),
mod_time timestamp without time zone DEFAULT now()
)
WITH (orientation=row, compression=no)
DISTRIBUTE BY HASH(id)
TO GROUP group_version1;
ALTER TABLE t_test1 ADD CONSTRAINT t_test1_pkey PRIMARY KEY (id);
- 测试语句
insert into t_test1 (state) values (${rNum})
配置jmeter
-
创建Thread Group
线程组 -
创建jdbc连接
jdbc连接 -
创建随机数变量
随机数 -
创建JDBC Request
request -
添加结果监控
结果监控
测试结果
JMeter监控
-
如上图，从JMeter的监控看，总体运行稳定，排除测试工具性能瓶颈影响测试结果的可能性。
数据库监控 -
如上图，在测试期间，数据库资源使用情况明显增加，但是总体运行稳定，压力没有达到数据库性能瓶颈。
测试结果 -
如上图，Guass DB在本次测试中的表现还是比较优秀的。吞吐量达到了每秒11000+，最快响应时间是6ms，平均响应时间是8ms，有99%的请求响应时间在29ms以内。最长响应时间是11s，但是从响应曲线（下图）中可以看出，最长响应时间都集中在开始的10s内，这段时间是JMeter创建线程阶段，因此可以基本判断，是创建过程影响了测试数据，因此，最长响应时间指标可忽略。
响应曲线
