性能测试报告模板

性能测试报告模板性能测试报告 Performance Test Report 性能测试报告 Performance Test Report 项目 XXX项目二期 版本 V1.00 作者 dayu 日期 2019.9.31 项目 XXX项目二期 版本 V1.00 作者 dayu 日期 2019.9.31 1.&#16

性能测试报告

 

Performance Test Report

 

 

 

项目

XXX项目二期

版本

V1.00

作者

dayu

日期

2019.9.31

 

 

 

1. 测试概述

1.1 测试目标

描述本次测试的意义和目标

本次测试的目的在于探查XXX项目二期重构环境的系统业务处理性能,以及在高负载情况下的系统表现。

1.2 指标和术语

描述本次测试中涉及到的性能指标术语

术语

释义

并发数

测试时同时系统发出事务请求的数量,并发线程数用以模拟同时与系统建立连接的用户。

TPS(每秒事务数)

在每秒时间内系统可处理完毕的事务数。TPS很大程度体现系统性能能力。

错误率

经系统处理的事务出现错误的概率,对应着实际用户使用系统功能失败的情况。理想情况下错误率应保持极低水平。

资源占用率

服务器端各关键资源的使用比例,用于衡量系统硬件能力

 

 

2. 环境、工具

列出本次测试所涉服务器、客户机和测试工具

2.1 测试环境

服务器:

应用

机器

CPU、内存配置

API

ip地址

16CPU、内存16G

MYSQL

ip地址

16CPU、内存16G

 

 

客户机:

操作系统

CPU

内存

Windows10 专业版

I3- 4170 3.70GHZ

8G

 

2.2 测试工具

核心工具

版本

备注

Jmeter

3.3

提供并发请求能力

PerfMon Metrics Collector

2.1

Jmeter插件,用于收集服务器资源使用信息

ServerAgent

2.2.1

以伺服形式发送服务器资源使用信息

nMon

16h v2

实时收集服务器资源信息

 

3. 测试方案

3.1 测试类型

不同的性能测试场景可能使用不同的测试类型,需要明确

本次性能测试将主要采用以下几种测试类型:

基准测试:

在小并发条件下,探测系统各性能指标表现,作为后续比对基础。

 

压力测试:

由于无法准确预估用户访问量,因此考虑使用压力测试方法。压力测试旨在通过不断 增加系统并发处理事务数,增加系统负载,直到系统到达性能瓶颈。以此推算出系统 可承载用户和事务请求数。

 

稳定性测试:

将系统置于较长时间高负载场景下,探测系统是否出现稳定性缺陷。

3.2 业务模型

针对系统接口,究竟哪些需要被纳入压测范畴?不同事务应该以何种比例被调用,这是需要建模设计的,也是性能测试的难点之一。

通过对于项目架构和业务场景分析,设计以下业务模型进行模拟和测试:

 

场景1:简单业务场景

业务名称

接口地址

请求类型

并发比例

登录

/login

post

1

查询用户信息

/queryMemberInfo

get

1

 

 

 

场景2:混合业务场景

业务名称

接口地址

请求类型

并发比例

登录

/login

post

1

查询用户信息

/queryMemberInfo

get

1

交易查询

/listOrderPage

get

1

订单创建

/createOrder

post

1

 

3.3 加密验签处理

由于系统对于所有事务请求都进行了加密验签处理,因此在本次性能测试中,需要对请求报文进行一致的加密和签名。处理逻辑如下:

使用APP同样的加密签名代码,导出jar包做为加密工具类

使用jmeter前置处理器-beanshell处理器调用上述jar包方法实现请求参数加密

l 将加密签名后的请求参数存储为变量,后续接口调用时使用

 

3.4 压力梯度

对于3.2所述场景,分别进行梯度加压,从100并发开始,每次递增100并发数,直至到达系统瓶颈。

 

4. 测试结果

4.1 聚合报告

标签

样本数

平均(响应时间ms)

最小

最大

错误率

吞吐量(/s)

登录

50

28

20

38

0.00%

4.5977

查询member信息

50

1602

1292

2042

0.00%

4.07133

查看交易

50

705

512

920

0.00%

4.37828

创建订单

50

86

60

119

0.00%

4.55083

总体

200

605

20

2042

0.00%

15.11716

场景1-10并发循环5

 

标签

样本数

平均(响应时间ms)

最小

最小

错误率

吞吐量(/s)

登录

500

7612

40

26725

0.00%

15.84987

查询用户信息

500

30871

2369

49719

0.00%

6.96233

总体

1000

19241

40

49719

0.00%

13.91517

场景1-500并发循环1

 

标签

样本数

平均(响应时间ms)

最小

最大

错误率

吞吐量(/s)

登录

550

8326

33

22360

0.00%

20.34851

查询用户信息

550

36071

4362

58485

0.36%

6.7585

总体

1100

22199

33

58485

0.18%

13.51069

场景1-550并发循环1

 

标签

样本数

平均(响应时间ms)

最小

最大

错误率

吞吐量(/s)

登录

4500

12408

87

46269

0.00%

4.68807

查询用户信息

4500

35383

3792

65036

0.00%

4.63027

查看交易

4500

22832

711

46812

0.02%

4.64518

创建订单

4500

24973

81

58698

0.13%

4.67591

总体

18000

23899

81

65036

0.04%

18.50308

场景2-450并发循环10

 

4.2 系统吞吐量

 性能测试报告模板

 

 

 场景1-550并发循环1

 

 性能测试报告模板

 

 

 场景2-450并发循环10

 

4.3 资源占用率

最优负载条件下:

CPU使用率

 性能测试报告模板

 

 

  

内存占用率

 性能测试报告模板

 

 

 

磁盘使用率

 性能测试报告模板

 

 

 

5. 分析和建议

结合收集到的数据,给出对于系统性能关键点的分析

5.1 测试结论分析

经过多次测试和数据报表分析,可以得出如下结论:

1) 当总体并发用户数为450-500时,系统具有最优性能表现;当事务并发数超过500时,事务失败率整体上升,系统到达性能拐点。

2) 多事务混合条件下,系统巅峰TPS在90左右,平均吞吐量在13-18/s。

3) 在小压力条件下(10并发),最大事务响应时间为查询用户信息事务的2042毫秒,平均在600毫秒左右系统。整体事务微观响应速度较优。

4) 满负载条件下,登录具有最佳的性能表现,平均响应时间为7000-12000毫秒;查询用户信息事务性能较差,平均响应时间在30000-40000区间。满负载条件下系统整体微观响应时间较差。查询用户接口由于其使用极为频繁,建议进行SQL效率调优

5) 系统资源方面,内存占用率始终处于高位水平(90%以上),磁盘空间由于日志写入而不断被占用。

         

5.2 问题

测试过程中发现了如下显著问题:

1) 加密验签功能并未生效-现阶段任何签名均可通过验签。属于功能性问题,不影响性能表现。

2) 日志文件由于不断写入导致磁盘占满,建议调低系统日志级别,并做好定期日志备份。

3) 内存占用处于高位水平,需要进一步探查原因。

 

(0)
编程小号编程小号
上一篇 2023-08-26 11:06
下一篇 2023-08-26 11:17

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注