银行系统压力测试报告.docx

银行系统压力测试报告.docx

《银行系统压力测试报告.docx》由会员分享，可在线阅读，更多相关《银行系统压力测试报告.docx（51页珍藏版）》请在冰豆网上搜索。

银行系统压力测试报告

XXXXXXXX

工作流系统压力测试报告

xxxxxxxxxx

二零一二年十月十八日

1测试概况

1.1测试范围及重点

本次压力测试主要针对华夏银行信用卡中心工作流系统，通过压力测试对新、旧工作流系统不同功能进行比较，分别对登录（包含打开任务中心）、打开工单页面、发起工作流、任务中心详细工单列表显示、收藏工单列表显示这几种场景进行测试。

1.2测试地点、人员

测试地点：

华夏银行信用卡中心

测试人员：

袁超

1.3测试环境

服务器地址

服务器机器型号

硬件配置

系统应用服务器1

 106.128.1.221

IBM8204-E8AUNIX

处理器：

PowerPC_POWER62-core3.5GHz，内存：

7712MB

系统应用服务器2

106.128.1.222

IBM8204-E8AUNIX

处理器：

PowerPC_POWER62-core3.5GHz，内存：

7712MB

数据库服务器

 106.128.1.221

IBM8204-E8AUNIX

处理器：

PowerPC_POWER62-core3.5GHz，内存：

7712MB

测试机

DellOptiplex320XP

处理器：

InterPentium4CPU3.00GHz3.00GHz，内存：

992MB

备注：

本次压力测试的网络环境为内部局域网。

1.4测试方法与工具

HP公司的LoadRunner创建虚拟用户脚本工具VirtualUserGenerator

HP公司的LoadRunner创建、运行实际场景工具Controller

HP公司的LoadRunner分析测试结果工具Analysis

Loadrunner的特点：

Loadrunner最大的特点就是它可以模拟多个并发用户进行负载测试。

这些用户在Loadrunner里被称为虚拟用户（Vuser），测试人员可以通过文档或数据库等方式很灵活得导入每个虚拟用户测试数据。

它不仅提供了友好的用户界面，并且还提供了以C语言为基准的测试脚本编辑接口，方便测试人员对所录的测试脚本进行编辑，从而扩展所要测试的功能。

Loadrunner的工作原理：

压力测试

MercuryLoadRunner向运行的测试代理机器Agent发送测试指令，测试代理机器运行经过编的脚本，模拟多个用户同时向服务器发出请求，测试在不同条件下服务器的响应情况。

性能测试工作原理：

LoadRunner通过VirtualUserGenerator捕捉客户端向服务器发送和接收的数据流形成脚本框架。

在此基础上利用的脚本定制向导自定义测试数据，使用数据表或随机数模拟现实环境的用户数据输入。

创建内容检查点，验证负载下的被测系统是否出现功能错误。

通过Controller并发指定数量的模拟用户运行以上设置好的脚本，确保测试尽可能接近真实环境，最大程度地反映系统的实际情况。

性能监控与分析

在前台使用LoadRunner模拟多用户并发访问的同时，后台将使用性能监控与分析工具对服务器系统的资源消耗情况进行性能分析。

用途

工具

厂商/自产

版本

压力测试

LoadRunner

HP

11.0

2测试方案

2.1测试数据准备

本次测试需要用到数据准备为“收藏工单列表显示”、“任务详细列表显示”两个场景使用，其中收藏工单列表内单页面存在40条数据，任务详细列表内单页面存在40条数据。

2.2测试场景

2.2.1登录系统（包括打开任务中心）

标识

输入条件

输入数据

1

60个用户

每个脚本用户数为60，全部同时启动，用户输入用户名和密码，点击登录按钮登录系统（登陆后页面默认显示任务中心）。

2.2.2任务详细列表显示

标识

输入条件

输入数据

2

100个用户

每个脚本用户数为100，同时全部加载，不同用户登录系统后点击任务中心任务数字链接，进入到任务详细列表显示页面。

3

150个用户

每个脚本用户数为150，同时全部加载，不同用户登录系统后点击任务中心任务数字链接，进入到任务详细列表显示页面。

2.2.3打开工单页面显示

标识

输入条件

输入数据

4

75个用户

每个脚本用户数为75，同时全部加载，不同用户登录系统后点击任务中心任务数字链接，进入到任务详细列表显示页面，点击普通任务，选取任一任务后，点击快速启动按钮，打开工单页面显示工单的全部信息。

5

100个用户

每个脚本用户数为100，同时全部加载，不同用户登录系统后点击任务中心任务数字链接，进入到任务详细列表显示页面，点击普通任务，选取任一任务后，点击快速启动按钮，打开工单页面显示工单的全部信息。

2.2.4发起工作流

标识

输入条件

输入数据

6

100个用户

每个脚本用户数为100，同时全部加载，不同用户登录系统后点击工单管理—短信问题，创建工单填写全部工单信息，点击发起工作流按钮，系统提示发起成功。

7

150个用户

每个脚本用户数为150，同时全部加载，不同用户登录系统后点击工单管理—短信问题，创建工单填写全部工单信息，点击发起工作流按钮，系统提示发起成功。

2.2.5收藏工单列表显示

标识

输入条件

输入数据

8

100个用户

每个脚本用户数为100，同时全部加载，不同用户登录系统后点收藏工单菜单，进入到收藏工单列表显示页面。

9

150个用户

每个脚本用户数为150同时全部加载，不同用户登录系统后点收藏工单菜单，进入到收藏工单列表显示页面。

2.3结果数据收集

对场景设计中计划进行执行测试，对每一个结果进行记录，主要获取以下几点：

分析概要、平均事务响应时间、每秒事务数、每秒点击数、吞吐量、服务器系统资源。

通过以上几点对系统做出压力测试的总结。

3测试实施情况

3.1测试时间和地点

测试时间：

2012年10月16日、17日

测试地点：

华夏银行信用卡中心

3.2参与测试人员

测试人员：

袁超

4压力测试详细记录

4.1登录系统（包括打开任务中心）

4.1.160人并发10分钟—新系统

1.平均事务响应时间

以上图为平均事务响应时间的详细信息，其中前5分钟平均事务响应时间为2.5-3秒，由于5分钟后服务器承受不住压力，服务奔溃导致平均事务响应时间增加。

2.每秒事务数

3.每秒点击数

4.吞吐量

5.UNIX系统资源

4.1.260人并发10分钟—旧系统

1.平均事务响应时间

以上图为平均事务响应时间的详细信息，其中前登录事务的平均事务响应时间为1.018秒。

2.每秒事务数

登录事务的每秒事务数平均值为50.993，最大值为56.313.

3.每秒点击数

4.吞吐量

5.UNIX系统资源

4.1.3小结

通过比较可以看到，旧系统的登录各项指标要好于新系统的登录功能，但是两个系统CPU使用平均值为都在94%左右，该数值相对非常高，如果并发人数继续增加，很可能引起服务器崩溃。

4.2任务详细列表显示

4.2.1100人并发10分钟—新系统

1、平均事务响应时间

平均事务响应时间的最大时间为1.002s，平均事务响应时间为0.93，响应十分迅速。

2、每秒事务数

如图所示每秒事务数最大值为105.75，平均值为101.942。

3、每秒点击数

4、吞吐量

5、UNIX系统资源

系统的平均使用率为22.516%，最大值为81.833%，表现良好。

4.2.2100人并发10分钟—旧系统

1、平均事务响应时间

2、每秒事务数

3、每秒点击数

4、吞吐量

5、UNIX系统资源

4.2.3150人并发10分钟—新系统

1、平均事务响应时间

2、每秒事务数

3、每秒点击数

4、吞吐量

5、UNIX系统资源

4.2.4150人并发10分钟—旧系统

1、平均事务响应时间

2、每秒事务数

3、每秒点击数

4、吞吐量

5、UNIX系统资源

4.2.5小结

平均响应时间

每秒事务数

每秒点击数

吞吐量

系统资源

100人（新）

0.93s

101.94

1331.06

11486434.8

22.5%

100人（旧）

0.427s

74.13

2009.27

2959070.6

86.1%

150人（新）

1.368s

100.2

1311.60

11315950.6

25.6%

150人（旧）

0.804s

58.10

1578.90

2807334.5

96.2%

通过以上比较显示，旧系统在任务详细列表显示的响应时间上要比新系统快很多，但是新系统的TPS要比旧系统高出很多，也说明新系统在处理该功能的能力较高，接口数据返回时间较慢，需要对读取任务详细列表接口处进行调优。

并且旧系统占用系统资源较高，而新系统在这方面表现良好，保持在22.5%—25.%之间。

4.3打开工单页面显示

4.3.175人并发10分钟—新系统

1、平均事务响应时间

2、每秒事务数

3、每秒点击数

4、吞吐量

5、UNIX系统资源

4.3.2100人并发10分钟—新系统

1、平均事务响应时间

2、每秒事务数

3、每秒点击数

4、吞吐量

5、UNIX系统资源

4.3.3小结

平均响应时间

每秒事务数

每秒点击数

吞吐量

系统资源

75人（新）

0.34s

13.90

392.56

2549536.69

67.0%

100人（新）

3.89s

3.93

114.57

2480011.94

90.0%

该场景只针对新系统进行了测试，当在75人并发时响应时间较迅速，100人并发时间较慢，两个场景的TPS都较低，且利用的系统资源都很高。

4.4发起工作流

4.4.1100人并发10分钟—新系统

1、平均事务响应时间

2、每秒事务数

3、每秒点击数

4、吞吐量

5、UNIX系统资源

4.4.2100人并发10分钟—旧系统

1、平均事务响应时间

2、每秒事务数

3、每秒点击数

4、吞吐量

5、UNIX系统资源

4.4.3150人并发10分钟—新系统

1、平均事务响应时间

2、每秒事务数

3、每秒点击数

4、吞吐量

5、UNIX系统资源

4.4.4150人并发10分钟—旧系统

1、平均事务响应时间

2、每秒事务数

3、每秒点击数

4、吞吐量

5、UNIX系统资源

4.4.5小结

平均响应时间

每秒事务数

每秒点击数

吞吐量

系统资源

100人（新）

0.66s

13.25

415.57

2071457.56

50.0%

100人（旧）

8.84s

2.89

228.23

1265306.19

52%

150人（新）

1.45s

11.02

404.19

2113855.94

57%

150人（旧）

10.35s

3.73

297.66

1292498.80

70.3%

通过以上比较显示，新系统在发起工作功能上要远远优越于旧系统，平均响应时间差距甚大，并且每秒事务数新系统平局高出旧系统4倍。

当并发人数增多的情况下，新系统的资源占用情况良好，保持在50%左右，但是旧系统增幅较大。

新系统的每秒事务数也不是很好，需要对系统本身进行调优，来加强系统处理事务的能力。

4.5收藏工单列表显示

4.5.1100人并发10分钟—新系统

1、平均事务响应时间

2、每秒事务数

3、每秒点击数

4、吞吐量

5、UNIX系统资源

4.5.2100人并发10分钟—旧系统

1、平均事务响应时间

2、每秒事务数

3、每秒点击数

4、吞吐量

5、UNIX系统资源

4.5.3150人并发10分钟—新系统

1、平均事务响应时间

2、每秒事务数

3、每秒点击数

4、吞吐量

5、UNIX系统资源

4.5.4150人并发10分钟—新系统

1、平均事务响应时间

2、每秒事务数

3、每秒点击数

4、吞吐量

5、UNIX系统资源

4.5.5小结

平均响应时间

每秒事务数

每秒点击数

吞吐量

系统资源

100人（新）

1.38s

25.61

619.38

3876243.8

56%

100人（旧）

8.33s

3.26

245.16

2030011.4

45%

150人（新）

2.82s

21.78

529.84

3746025.2

64%

150人（旧）

8.66

4.46

336.98

2781782.8

64%

通过以上比较显示，新系统在收藏工单列表显示功能上要明显优越于旧系统，平均响应时间差距很大，新系统平均响应时间为1.38s—2.82s，而旧系统的平均响应时间为8s左右，不易被用户所接受。

每秒事务数新系统平均高出旧系统6倍。

但是新系统的系统资源较高。

5总结

本次压力测试分别通过登录、任务详细列表显示、打开工单页面显示、发起工作流、收藏工单列表显示共计5个场景对新、旧系统进行了比较。

结果表明登录和任务详细列表显示场景中，旧系统的平均响应时间、每秒事务数数值都优越于新系统，但是这两个场景中旧系统消耗的系统资源较高，尤其是任务详细列表显示场景，所显示的系统资源消耗已经超过86.1%，不易被用户所接受。

其他4个场景结果显示新系统的各项数值够比旧系统要好，尤其是以下场景新系统较为突出，如：

打开工单页面显示、发起工作流、收藏工单列表显示。

在日常工作中用户经常用到的场景为：

任务详细列表显示、工单页面打开、发起工作流，所以综合判断，新系统要优异与旧系统。

经过压力测试新系统可以支持150人同时并发，由此推断可以支持750人以上同时在线对系统进行操作。

但是登录场景和任务详细列表显示场景，新系统的平均响应时间不理想，需要对读取任务详细列表接口处进行调优进行调优。

发起工作流和收藏列表显示功能需要对系统程序就行调优。

目前显示当前服务器对系统应用支持除登录模块外其他场景良好，鉴于登录情况不良，建议除对系统本身进行调优外，可以适当提高服务器配置。

可以达到缩短平均响应时间和提交系统处理能力的效果。