web端性能测试报告.docxVIP

Xxxx

性能测试报告

文档编号：

密级：

版本信息：Vxxxx

建立日期：2017-06

创建人：XXX

版本编号

*变化

状态

简要说明〔变更内容和变更范围〕

日期

测试人

批准日期

批准人

VXXX

A

新增

2017-6-30

XXXX

引言

编写目的

根据性能测试方案，给出结果和分析以及结论和建议。

测试方案预期读者：开发人员、测试人员、和工程相关人员。

工程背景

工程名称

XXXX系统

工程简称

XXXX

工程编号开发者

XXXXX

用户

各个XXXX站点

术语定义

虚拟用户：通过执行测试脚本模仿真实用户与被测试系统进行通信的进程或线程。

测试脚本：通过执行特定业务流程来模拟真实用户操作行为的脚本代码。

场景：通过组织假设干类型、假设干数量的虚拟用户来模拟真实生成环境中的负载场景。

集合点：用来确定某一步操作由多少虚拟用户同步执行〔并发〕。

事务：设置事务是为了明确某一个或多个业务或者某一个按钮操作的响应时间。

HPS:每秒点击数，一般情况下，与TPS成正比。

TPS：每秒事务数，是指每秒内，每个事务通过、失败以及停止的次数，可以确定系统在任何给定时刻的实际事务负载。

系统资源利用率：是指在对被测试系统执行性能测试时，系统部署的相关应用效劳器、数据库等系统资源利用，比方CUP，内存，网络等。

测试业务及性能需求

效劳器配置如下：

Web效劳器：

操作系统：Windows7旗舰版64位；

处理器：Intel(R)Xeon(R)CPUI5-5200U@2.20GHz2.20GHz

内存：8GB

业务名称

模拟实际生成环境指标

说明

XXX接口

假设一个站一天任务流水100条，20个站一个月整个XXX大概6W条，因此模拟Sfjc_jourtask表中造30W条的数据量大概在接近半年的流水

效劳器cup使用率、内存使用量不能高于90%前提下

网络带宽的使用量不能高于80%

系统响应时间控制在10s内

场景设及计执行结果

场景设计

序号〔负载〕

场景名称

用户总数

执行时间

用户递增策略

递增数量

递增间隔

1

CJ-TJ_001

20

5min

2

10S

2

CJ-TJ_002

40

5min

2

10S

3

CJ-TJ_003

60

5min

2

10S

4

CJ-TJ_004

80

5min

2

10S

测试结果

“提交”事务情况汇总

场景名称

事务名称

响应最小时间〔s〕

平均响应时间〔s〕

最大响应时间〔s〕

90%事务的平均响应时间〔s〕

CJ-TJ_001

提交

0.152

1.155

2.505

1.539

CJ-TJ_002

提交

0.272

2.197

3.643

2.948

CJ-TJ_003

提交

0.152

3.043

5.114

4.194

CJ-TJ_004

提交

0.198

4.726

9.534

6.947

每秒点击量〔hps〕

CJ-TJ_001和CJ-TJ_004点击率在大概维持在13-15左右的点击率

2、CJ-TJ_003和CJ-TJ_004点击率在场景持续变发60或者80个用户时，hPS会有明显的下降

吞吐量〔CJ-TJ_001-2-3-4〕大体一致

事务〔CJ-TJ_002〕

平均事务响应时间〔CJ-TJ_002〕

每秒事务数〔TPS〕

由于tps一般和hps保持正比例关系，介于hps在13-15左右，监测tps的数据也大概在12-14。

效劳器资源监控

场景名称

Cpu

内存

网络

CJ-TJ_001

CJ-TJ_002

CJ-TJ_003

CJ-TJ_004

90%

1.0G

20M

测试结论

四个场景监控发现效劳端的CPU到达90%左右前提下，HPS(每秒的请求数)大概维持在12-15左右，在增加用户数使CPU到超负荷状态，并不能增加HPS的请求数，可得到瓶颈在效劳器的cpu上；依照当前效劳器的硬件配置条件有发现，在请求数长时间40Vuser前提下观察的HPS请求数稳定在13左右，当变发60个Vuser时，HPS的请求数有明显的下降，同理可观察80个Vuser也由此现象。

总之，本次测试结论是本配置下，适合并发的用户在40-60个之间为最正确值。