环境

• 环境搭建参考之前写过的文章CentOS7 安装 Gauss DB 200 单节点

场景 - 单点更新 (OLTP)

背景

1000W条记录基础上通过主键更新单条记录，测试数据库在简单场景下的读写性能。

设计

单表1000W行数据，100个并发连接在10秒内连接，连续主键更新1000W次。

准备

• 创建测试表

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);

• 测试语句

update t_test1 set state = ${rNum} where id = ${rNumQw}

配置jmeter

• 创建Thread Group

  
  

  

• 创建jdbc连接

  
  

  

• 创建修改值随机数变量

  
  

  

• 创建主键值随机数变量

  
  

  

• 创建JDBC Request

  
  

  

测试结果

• 如上图，从JMeter的监控看，总体运行稳定，排除测试工具性能瓶颈影响测试结果的可能性。

  
  

  

• 如上图，在测试期间，数据库资源使用情况明显增加，但是总体运行稳定，压力没有达到数据库性能瓶颈。

  
  

• 
  

• 如上图，Guass DB在本次测试中的表现还是比较优秀的。吞吐量达到了每秒11000+，最快响应时间是1ms，平均响应时间是7ms，有99%的请求响应时间在25ms以内。最长响应时间是3s，但是从响应曲线（下图）中可以看出，最长响应时间都集中在开始的10s内，这段时间是JMeter创建线程阶段，因此可以基本判断，是创建过程影响了测试数据，因此，最长响应时间指标可忽略。

•