新华人寿渠道管理系统性能测试报告.docx

新华人寿渠道管理系统性能测试报告

2010年5月21日

文档信息
文档标题
新华人寿渠道管理系统性能测试报告
版 本 号
v1.1
版本日期
2010-5-14
打印日期

文 件 名
新华人寿渠道管理系统性能测试报告
归档目录

管理人员

审批信息
姓名
部门/角色
意见
日期

修改历史
版本
日期
修改说明
修改人
1.0
2010-5-14
草稿

1.1
2010-5-20
初稿

目录
1. 概述 5
1.1项目背景 5
1.2测试目的 5
2. 测试范围 6
2.1测试目标 6
2.2业务模型 6
3. 测试环境 8
3.1系统架构图 8
3.2测试环境机器配置表 8
4. 测试方法 9
4.1基准测试 9
4.2单交易负载测试 9
4.3混合场景负载测试 9
3.4性能测试案例设计 10
3.4.1系统登录 10
3.4.2人员信息查询 10
3.4.3销售团队查询 11
3.4.4网点信息查询 11
3.4.5人员基本信息维护 12
3.4.6销售团队信息维护 12
3.4.7网点基本信息维护 一三
3.5性能测试场景设计 一三
3.5.1系统登录 一三
3.5.2人员信息查询 14
3.5.3销售团队查询 14
3.5.4网点信息查询 14
3.5.5人员基本信息维护 14
3.5.6销售团队信息维护 一五
3.5.7网点基本信息维护 一五
3.5.8混合场景负载测试 一五
5. 测试计划 17
6. 测试结果 一八
6.1基准测试 一八
6.1.1系统登录 一八
6.1.2人员查询 一八
6.1.3团队查询 一八
6.1.4网点查询 19
6.1.5人员维护 19
6.1.6团队维护 19
6.1.7网点维护 19
6.2单交易负载测试 19
6.2.1系统登录 19
6.2.2人员查询 26
6.2.3 团队查询 31
6.2.4 网点查询 32
6.2.5 人员维护 33
6.2.6 团队维护 33
6.2.7 网点维护 34
6.3混合场景负载测试 39
6.4其他负载测试 41
6.4测试结论与建议 42
结论 42
建议 43
7. 附件1： 45

1. 概述
1.1项目背景
本系统的目标是使渠道业务日常管理电子化、简单化，对各渠道业务发展提供强大的后台数据支持。
现阶段公司迅速发展，业务迅速扩张，业务拓展模式不断创新。公司的销售渠道涉及到个人营销保险、团体保险、银行保险、至尊理财、电话营销保险等多个领域，由于各个领域的保险特点不同、管理方法也呈现出多样性。需要的是一套能够处理并突出体现各个保险领域的特性的销售管理系统，从管理角度出发对销售的各个阶段进行控制，对销售人员进行管理，为销售人员提供从培训、售前、售后以及佣金结算等一系列完整的服务支持。为达到这一目标，需要利用现代的信息处理技术和科学手段，全面实现销售管理中的各项要求，通过计算机辅助实现管理的科学化、规范化、系统化与自动化，与业务系统一起建立一套完整的保险管理系统和网络。
1.2测试目的
通过模拟，在测试环境上尽量真实再现新华人寿银代渠道销售管理系统生产环境的日常业务量高峰时的场景。通过结果分析，查看哪些业务出现响应时间长，交易失败的情况。查看新华人寿银代渠道销售管理系统是否符合设计的性能要求。
2. 测试范围
2.1测试目标
性能测试是针对系统并发处理能力、交易响应时间等性能指标所进行的测试。目的是在尽可能模拟生产环境的前提下，单一渠道方面的性能，实现以下目标（相关指标参考合同附件）：
Ø 模拟系统在实际生产环境下峰值时的系统处理能力及性能表现。
Ø 检测软件中的问题：通过并发测试执行，揭示程序中的隐含的问题或冲突，从而修复系统中的薄弱环节。
Ø 通过对各项测试及监控结果的综合分析，发现、定位性能瓶颈，为改善系统性能提供整体优化方案，为后期性能调优提供参考依据。
Ø 保证在生产环境的业务和用户量下，性能满足业务人员操作需求，主要需求如下：
l 日常平均在线用户数500人，高峰期在线用户数700人。
注：目前核心业务系统有效用户数：24045，核心业务系统日常在线用户数平均为2.6K ，高峰期在线用户数为3.6K，渠道系统按照核心系统用户数量的20%计算，所以平均在线用户数量为500，高峰为700。
l 薪资考核计算效率：
ü 考核计算、薪资计算均能够在2-4小时内完成。
l 其他操作时效要求如下：
ü 提交信息维护，系统应在2秒内响应。
ü 按照机构号或人员编码查询信息详情，系统应在2秒内响应。
ü 按照条件查询清单，系统应在一五-30秒内响应。
ü 按照条件生成统计报表，根据复杂性，系统响应时间不同，最慢应在5分钟内响应。
ü 按分支机构进行考核确认，系统应在一五分钟内完成。

2.2业务模型
序号
业务模块
业务名称
类型
数据量
平均用户数
最大用户数
响应时间
1
系统登录
系统登录
登录

500
700
5秒
2
人员管理
人员查询
查询
40000
500
700
30秒
3
网点管理
网点信息查询
查询
3000
500
700
30秒
4
团队管理
销售团队查询
查询
3000
500
700
30秒
5
人员管理
人员修改
交易

500
700
5秒
6
网点管理
网点修改
交易

500
700
5秒
7
团队管理
团队修改
交易

500
700
5秒
8
薪资考核普处理
批处理管理
批处理

500
600
2-4小时

注：业务模型选择参考了运维部门提供的菜单使用频率参考

此处需要对性能场景设计，先做个简单说明。30并发的测试场景，以登录为例，每个并发用户，迭代登录20次，也就是说30并发，在1.5分钟内前后共有30*20=600人次登录系统， 40并发场景，在2分钟内有40*20=800人次登录，50并发场景，在2.5分钟内有50*20=1000人次登录。
3. 测试环境
3.1系统架构图

3.2测试环境机器配置表
系统
服务器
配置
操作系统及安装软件
台数
应用服务器
应用服务器
服务器:1*2.6G双核
2G 内存 320G 硬盘 1电源
Red hat nash 5.1.19.6
JDK1.6.0
JBoss 4
1
销售管理平台数据库和元数据数据库
数据库服务器
服务器:1*2.6G双核
4G 内存 320G 硬盘 1电源
Red hat nash 5.1.19.6
Oracle 10g
1

4. 测试方法
4.1基准测试
测试环境确认之后，对业务模型中涉及的每种业务（系统登录、人员查询、团队查询、网点查询、人员维护、网点维护、团队维护）做基准测试。目的是检查业务本身是否存在性能缺陷。同时为将来的混合场景负载测试性能分析提供参考依据。

场景设置：
编写测试客户端向新华人寿银代渠道销售管理系统应用服务器发送业务请求并接收返回结果的脚本，在系统无压力情况下运行10次迭代，每次迭代间等待1秒，取业务的平均响应时间作为衡量指标。
4.2单交易负载测试
单交易负载测试是对业务模型中涉及的每种业务（系统登录、人员查询、团队查询、网点查询、人员维护、网点维护、团队维护）加上一定量的负载，进行测试以获取该交易的性能指标。目的是为了验证这些典型交易是否存在并发问题，并获取其响应时间，作为混合场景测试中业务模型配比的参考。

场景设置：
制作单个交易的性能测试脚本，在负载测试工具中设置并发用户数等于30、40、50，每秒登陆10个用户，迭代20次，每次迭代等待1秒，忽略思考时间，获取平均响应时间。30并发=600人次，40并发=800人次，50人次=1000人次。

4.3混合场景负载测试
混合场景负载测试是按照业务模型的约定，在一定量的并发情况下测试以下指标：业务的平均交易响应时间、应用服务器、数据库服务器的资源使用情况、交易正确率等。通过性能测试，可以模拟实际生产环境中在业务处理高峰期实物资产管理系统的压力情况，得到此时的实物资产管理系统性能表现数据，为系统的实际上线运行提供可靠的参考。

场景设置：
按照业务模型比例设置测试场景，设置并发量60，每1秒登陆10个用户，忽略思考时间，每次运行测试一五分钟，每次迭代间等待1秒，收集系统性能变化曲线。
4.4性能测试案例设计
4.4.1系统登录
系统登录
脚本名称
系统登录
程序版本

用例编号
XH-XTDL-01
子系统

测试目的
测试用户登录的并发能力及系统响应时间。
特殊说明
目标产生大压力，忽略全部思考时间。
前提条件
应用程序已经部署，同时存在不同身份的系统使用用户
步骤
操作
是否设置集合点
是否设定事务
事务名称
说明
1
打开登录页
否
否

2
输入用户名、密码、选择机构
否
否

3
点击“登录”按钮
是
是
登录
设置检查点
4
登陆后展现页面信息
否
否

5
注销用户
否
是
注销

编制人员

编制日期
2010-04-一三
4.4.2人员信息查询
人员信息查询
脚本名称
人员查询
程序版本

用例编号
XH-RYCX-02
子系统

测试目的
测试人员信息查询功能系统响应时间。
特殊说明
目标产生大压力，忽略全部思考时间。
前提条件
应用程序已经部署
步骤
操作
是否设置集合点
是否设定事务
事务名称
说明
1
登录系统
否
否

2
选择人员管理à人员信息管理à人员信息查询
否
是
进入人员查询菜单

3
输入查询条件
否
是
录入人员查询条件

4
点击“查询”按钮
否
是
人员查询

5
勾选需要查询的人员记录，点击明细按钮
否
是
人员明细
设置检查点
编制人员

编制日期
2010-04-一三

4.4.3销售团队查询
销售团队查询明细
脚本名称
销售团队查询
程序版本

用例编号
XH-TDCX-03
子系统

测试目的
测试销售团队查询功能的系统响应时间。
特殊说明
目标产生大压力，忽略全部思考时间。
前提条件
应用程序已经部署
步骤
操作
是否设置集合点
是否设定事务
事务名称
说明
1
登录系统
否
否

2
选择销售团队管理à销售团队查询明细
否
是
进入团队查询菜单

3
点选查询条件
否
是
录入团队查询条件

4
点击“查询”按钮
否
是
团队查询

5
勾选需要记录，点击销售团队明细按钮
否
是
团队明细
设置检查点
编制人员

编制日期
2010-04-一三
4.4.4网点信息查询
网点基本信息查询
脚本名称
网点信息查询
程序版本

用例编号
XH-WDMX-04
子系统

测试目的
测试网点基本信息维护系统响应时间。
特殊说明
目标产生大压力，忽略全部思考时间。
前提条件
应用程序已经部署
步骤
操作
是否设置集合点
是否设定事务
事务名称
说明
1
登录系统
否
否

2
进入菜单：银保渠道à网点管理à网点信息维护
否
是
进入网点查询菜单

3
输入查询条件
否
是
录入网点查询条件

4
点击“查询”按钮
否
是
网点查询

5
点击“明细”按钮
否
是
网点明细

编制人员

编制日期
2010-04-一三
4.4.5人员基本信息维护
人员基本信息维护
脚本名称
人员入司
程序版本

用例编号
XH-RYRS-05
子系统

测试目的
测试人员入司的系统响应时间。
特殊说明
目标产生大压力，忽略全部思考时间。
前提条件
应用程序已经部署
步骤
操作
是否设置集合点
是否设定事务
事务名称
说明
1
登录系统
否
否

2
进入菜单：银保渠道à人员管理à人员信息管理à人员信息维护
否
是
进入人员新增菜单

3
点击新增按钮
否
是
进入人员修改界面
设置检查点
4
录入或者选录人员信息
否
是
人员信息录入

5
点击“新增”按钮
否
是
人员入司

编制人员

编制日期
2010-04-一三
4.4.6销售团队信息维护
销售团队信息维护
脚本名称
团队新增
程序版本

用例编号
XH-TDXZ-06
子系统

测试目的
测试团队新增的系统响应时间。
特殊说明
目标产生大压力，忽略全部思考时间。
前提条件
应用程序已经部署
步骤
操作
是否设置集合点
是否设定事务
事务名称
说明
1
登录系统
否
否

2
进入菜单：银保渠道à销售团队管理à销售团队维护
否
是
进入团队维护菜单

3
点击新增按钮
否
是
进入团队新增界面

4
录入或者选录团队信息

团队信息录入

5
点击“新增”按钮
否
是
团队新增

编制人员

编制日期
2010-04-一三
4.4.7网点基本信息维护
网点基本信息维护
脚本名称
网点新增
程序版本

用例编号
XH-WDWH-07
子系统

测试目的
测试网点基本信息维护系统响应时间。
特殊说明
目标产生大压力，忽略全部思考时间。
前提条件
应用程序已经部署
步骤
操作
是否设置集合点
是否设定事务
事务名称
说明
1
登录系统
否
否

2
进入菜单：网点管理à网点信息维护
否
是
进入网点维护菜单

3
点击新增按钮
否
是
进入网点新增界面
设置检查点
4
填选网点信息
否
是
填写网点信息

5
点击新增按钮
否
是
网点新增

编制人员

编制日期
2010-04-一三
4.4.8 薪资考核批处理
网点基本信息维护
脚本名称
薪酬计算
程序版本

用例编号
XH-XZKH-20
子系统

测试目的
测试薪资考核系统响应时间。
特殊说明
通过前台操作，对系统造成负载压力
前提条件
应用程序已经部署
步骤
操作
是否设置集合点
是否设定事务
事务名称
说明
1
登录系统
否
否

2
进入菜单：银保渠道à批处理管理à薪酬计算申请
否
是
进入薪酬计算菜单

3
选择部门、月份
否
是
选择薪酬计算条件

4
点击申请按钮
否
是
薪酬计算申请

编制人员

编制日期
2010-05-24

4.5性能测试场景设计
4.5.1系统登录
序号
场景名称
场景说明
执行脚本
用户总数
循环数量
操作间隔
并发
发出间隔
循环间隔
退出间隔
同步点
1
系统登录
基准测试
系统登录
1
10
0
0
1
0
0
2
系统登录
30并发
系统登录
30
20
0
10
1
10
0
3
系统登录
40并发
系统登录
40
20
0
10
1
10
0
4
系统登录
50并发
系统登录
50
20
0
10
1
10
0
4.5.2人员信息查询
序号
场景名称
场景说明
执行脚本
用户总数
循环数量
操作间隔
并发
发出间隔
循环间隔
退出间隔
同步点
1
人员查询
基准测试
人员查询
1
10
0
0
1
0
0
2
人员查询
30并发
人员查询
30
20
0
10
1
10
0
3
人员查询
40并发
人员查询
40
20
0
10
1
10
0
4
人员查询
50并发
人员查询
50
20
0
10
1
10
0
4.5.3销售团队查询
序号
场景名称
场景说明
执行脚本
用户总数
循环数量
操作间隔
并发
发出间隔
循环间隔
退出间隔
同步点
1
团队查询
基准测试
团队查询
1
10
0
0
1
0
0
2
团队查询
30并发
团队查询
30
20
0
10
1
10
0
3
团队查询
40并发
团队查询
40
20
0
10
1
10
0
4
团队查询
50并发
团队查询
50
20
0
10
1
10
0
4.5.4网点信息查询
序号
场景名称
场景说明
执行脚本
用户总数
循环数量
操作间隔
并发
发出间隔
循环间隔
退出间隔
同步点
1
网点查询
基准测试
网点查询
1
10
0
0
1
0
0
2
网点查询
30并发
网点查询
30
20
0
10
1
10
0
3
网点查询
40并发
网点查询
40
20
0
10
1
10
0
4
网点查询
50并发
网点查询
50
20
0
10
1
10
0
4.5.5人员基本信息维护
序号
场景名称
场景说明
执行脚本
用户总数
循环数量
操作间隔
并发
发出间隔
循环间隔
退出间隔
同步点
1
人员入司
基准测试
人员入司
1
10
0
0
1
0
0
2
人员入司
30并发
人员入司
30
20
0
10
1
10
0
3
人员入司
40并发
人员入司
40
20
0
10
1
10
0
4
人员入司
50并发
人员入司
50
20
0
10
1
10
0
4.5.6销售团队信息维护
序号
场景名称
场景说明
执行脚本
用户总数
循环数量
操作间隔
并发
发出间隔
循环间隔
退出间隔
同步点
1
团队新增
基准测试
团队新增
1
10
0
0
1
0
0
2
团队新增
30并发
团队新增
30
20
0
10
1
10
0
3
团队新增
40并发
团队新增
40
20
0
10
1
10
0
4
团队新增
50并发
团队新增
50
20
0
10
1
10
0
4.5.7网点基本信息维护
序号
场景名称
场景说明
执行脚本
用户总数
循环数量
操作间隔
并发
发出间隔
循环间隔
退出间隔
同步点
1
网点新增
基准测试
网点新增
1
10
0
0
1
0
0
2
网点新增
30并发
网点新增
30
20
0
10
1
10
0
3
网点新增
40并发
网点新增
40
20
0
10
1
10
0
4
网点新增
50并发
网点新增
50
20
0
10
1
10
0
4.5.8薪资考核计算测试
序号
场景名称
场景说明
执行脚本
用户总数
循环数量
操作间隔
查询时间
一次查询
二次查询
三次查询
四次查询
1
薪资考核
基准测试
薪资考核
1
1
0
5
10
一五
20
2
薪资考核
30并发计算
薪资考核
30
1
0
30
60
120
240
3
薪资考核
40并发计算
薪资考核
40
1
0
30
60
120
240
4
薪资考核
50并发计算
薪资考核
50
1
0
30
60
120
240
注：薪酬计算场景比较特殊，计算完成时没有在前台提示，所以才用roadrunner前台提交计算申请，记录开始时间；通过去数据库查询或者在前台界面查询计算结果 ，直到查询出需要的所有结果，记录时间。结束时间-开始时间约为薪资考核计算所用时间。所有计算应该在4小时之内完成计算。
4.5.9混合场景负载测试
由于压力演示环境并发用户适量限制，混合场景设置为60人并发混合场景，主要是测试使用频率最高查询功能。
序号
场景名称
场景说明
执行脚本
用户总数
循环数量
操作间隔
并发
发出间隔
循环间隔
退出间隔
同步点
1
系统登录
60并发
系统登录
0
运行一五分钟
0
1
1
5
0
人员查询
人员查询
30
团队查询
团队查询
20
网点查询
网点查询
10
人员修改
人员修改
0
网点修改
网点修改
0
团队修改
团队修改
0
薪酬计算

薪酬计算
前台提交计算申请，后台一直运行
注：薪酬计算场景比较特殊，计算完成时没有在前台提示，所以才用roadrunner前台提交计算申请，后台一直运行计算，作为负载。
5. 测试计划
内容
开始日期
结束日期
人力资源
金涛
李勇君
王利鹏
测试环境和版本确认
2010-4-12
2010-4-12
ü
ü

测试方案编写与评审
2010-4-一三
2010-4-16
ü
ü

测试数据准备
2010-5-07
2010-5-10

ü
ü
测试脚本开发
2010-5-10
2010-5-11

ü
ü
测试场景设置
2010-5-12
2010-5-一三

ü
ü
测试执行
2010-5-12
2010-5-一三

ü
ü
测试结果分析
2010-5-14
2010-5-14
ü
ü
ü
测试报告编写
2010-5-14
2010-5-14
ü
ü
ü
系统调优后测试
2010-5-17
2010-5-20

ü

修改测试报告
2010-5-20
2010-5-21

ü

报告评审
2010-5-24
2010-5-25

6. 测试结果
6.1基准测试
6.1.1系统登录

6.1.2人员查询

6.1.3团队查询
平均响应时间

6.1.4网点查询

6.1.5人员维护
待测
6.1.6团队维护
待测
6.1.7网点维护

6.2单交易负载测试
6.2.1系统登录
平均响应时间（单位：秒）
30人并发：

40人并发：

50人并发

响应时间分析：
基准响应时间为：0.675s，在单交易负载测试环境下，30并发系统响应时间为3.386s，40并发系统响应时间为4.82s；50并发用户系统响应时间为6.002s。30并发、40并发，响应时间小于5秒，符合测试目标；50登录响应时间大于测试目标要求时间。
CPU利用率（单位：百分比）
30人并发：

40人并发：

50人并发

CPU利用率分析：
在负载测试过程中，随着压力的增大，应用服务器使用：
30并发情况下，应用服务器cpu使用率为峰值80%，平均使用率77%，在正常范围之内；
40并发情况下，应用服务器cpu使用率为峰值100%，平均使用率81%，处以满负荷运行；
50并发情况下，应用服务器cpu使用率为峰值89%，平均使用率78% ，处以满负荷运行；
数据库服务器cpu使用率，峰值均未超过50%，平均值均为超过 35%，使用正常；
内存
应用服务器物理内存使用情况如图，物理内存容量为2G，空闲约为50M。

数据库服务器物理内存使用情况如图，物理内存容量为4G，运行负载时空闲最大约为500M，最小为0；

吞吐量（单位：字节/秒）：
30人并发：

40人并发

50人并发

吞吐量分析：
30人并发吞吐量平均约为9.2M/S, 峰值约为14.5M/S,；
40人并发吞吐量平均约为9.7M/S,峰值约为16.5M/S,
50人并发吞吐量平均约为8.8M/S,峰值约为17 M/S,
由此可见30~40并发之间，随着用户并发数增加平均吞吐量呈上升趋势，40~50并发并发用户数量增加了，平均吞吐量反而有所减小，由于并发用户超过系统响应能力，所以系统在现有环境下的处理能力约为9.5M/S。
处理事务数量(单位：个/ 秒)
30并发

40并发：

50并发:

处理事务数量分析：
30并发处理事务量 6.3个/秒，40并发处理事务量10.4个/秒，50并发处理事务量6个/秒，由此可见，40并发系统处理能力最高。
6.2.2人员查询
平均响应时间（单位：秒）
30人并发：

40人并发：

50人并发

响应时间分析：
基准响应时间为：0.286s，在单交易负载测试环境下，30并发系统响应时间为5.086s，40并发系统响应时间为6.371s；50并发用户系统响应时间为8.一三3s。系统在一五-30秒之内返回结果，完成测试目标要求。
CPU利用率（单位：百分比）
30人并发：

40人并发：

50人并发

CPU利用率分析：
在负载测试过程中，随着压力的增大，应用服务器的CPU成为系统瓶颈。
30并发情况下，应用服务器cpu使用率为峰值99%，平均使用率84%，处以满负荷运行；
40并发情况下，应用服务器cpu使用率为峰值99%，平均使用率86% ，处以满负荷运行；
50并发情况下，应用服务器cpu使用率为峰值99%，平均使用率85%，处以满负荷运行；
数据库服务器cpu使用率，峰值均未超过60%，平均值均约为超过 35%，使用正常；
吞吐量（单位：字节/秒）：
30人并发：

40人并发

50人并发

吞吐量分析：
30人并发吞吐量平均约为7.5M/S, 峰值约为10M/S,；
40人并发吞吐量平均约为7.7M/S,峰值约为14.5M/S,
50人并发吞吐量平均约为7.7M/S,峰值约为10M/S,
由此可见系统在现有环境下，处理能力约为7.6M/S。
处理事务数量(单位：个/ 秒)
30并发

40并发：

50并发:

6.2.3 团队查询
平均响应时间（单位：秒）
30人并发：

40人并发：

50人并发

响应时间分析：
基准响应时间为：0.1一八s，在单交易负载测试环境下，30并发系统响应时间为1.355s，40并发系统响应时间为1.681s；50并发用户系统响应时间为2.101s。系统在一五-30秒之内返回结果，完成测试目标要求。
团队查询其他参数结果类似于人员查询。
6.2.4 网点查询
平均响应时间（单位：秒）
30人并发：

40人并发：

50人并发

响应时间分析：
基准响应时间为：0.19s，在单交易负载测试环境下，30并发系统响应时间为2.988s，40并发系统响应时间为3.509s；50并发用户系统响应时间为4.832s。系统在一五-30秒之内返回结果，完成测试目标要求。
网点查询其他参数结果类似于人员查询。
6.2.5 人员维护
待测
6.2.6 团队维护
待测
6.2.7 网点维护
平均响应时间（单位：秒）
30人并发：

40人并发：

50人并发

响应时间分析：
基准响应时间为：0.208s，在单交易负载测试环境下，30并发系统响应时间为0.594s，40并发系统响应时间为1.5s；50并发用户系统响应时间为1.35s。网点新增系统响应时间小于5秒，符合测试目标。
CPU利用率（单位：百分比）
30人并发：

40人并发：

50人并发

吞吐量（单位：字节/秒）：
30人并发：

40人并发

50人并发

吞吐量分析：
30人并发吞吐量平均约为7.5M/S, 峰值约为12.5M/S,；
40人并发吞吐量平均约为8.5M/S,峰值约为一三M/S,
50人并发吞吐量平均约为7M/S,峰值约为10M/S,
由此可见30~40并发之间，随着用户并发数增加，吞吐量呈上升趋势，40~50并发并发用户数量增加了，吞吐量反而有所减小。
处理事务数量(单位：个/ 秒)
30并发

40并发：

50并发:

6.3混合场景负载测试
平均响应时间（单位：秒）：

CPU利用率

吞吐量（单位：字节/秒）：

混合场景结果：
混合查询场景60用户并发，人员查询响应时间为：4.069s，网点查询响应时间为：3.672s，团队查询响应时间为：3.266s，系统在一五-30秒之内查询出结果，完成测试目标要求。
应用服务器cpu峰值使用率为99%，平均使用率为88%，满负载工作；
数据库服务器cpu峰值使用率为70%，平均使用率为20%，工作在正常范围；
6.4其他负载测试
测试场景设置如下：
序号
场景名称
场景说明
执行脚本
用户总数
循环数量
操作间隔
并发
发出间隔
循环间隔
退出间隔
同步点
1
系统登录
100并发
系统登录
0
运行一五分钟
0
1
1
5
0
人员查询
人员查询
40
团队查询
团队查询
30
网点查询
网点查询
30
人员修改
人员修改
0
网点修改
网点修改
0
团队修改
团队修改
0
响应时间如下：

系统后台报异常，错误日志如下图。需要对系统进行调优。

6.4测试结论与建议
结论
在目前测试环境下（以混合场查询景为例）。
应用服务器cpu和物理内存容量成为系统瓶颈。
对系统施加压力时，cpu queue length（排队进程）队列平均长度在5~10，使用率达到80%以上，现有双核cpu不能及时处理并发请求，形成系统瓶颈，需要升级。
内存方面，物理内存空闲约50M，若要并发处理更多用户，需要升级。

数据库服务器物理内存成为系统瓶颈。
数据库受内存制约，物理内存剩余80M，形成系统瓶颈，需要升级。
Cpu使用率峰值未超过55%，平均使用率在50%，进程有排队现象（Queue Lenght），若需要处理更大数量的并发，建议增加cpu数量，增强并发处理能力。

综上，应用服务器和数据库服务器，对系统性能都有所制约。
建议
根据本次性能测试结果，对系统提出以下改进性能的建议：
l 对于测试环境：
1． 建议对现有硬件经行升级。参考配置见 附件1；
2． 现有服务器部署于百兆局域网内，100M带宽的实际传输速度为于12M左右，本次测试使用10M，如果需要处理更大量的并发请求，服务器需要部署在千兆网内，服务器网卡使用100/1000M网卡。
3． 应用服务器压力较大，若使用范围是是全国范围，建议考虑负载均衡；
l 对于程序：
1． 100用户并发查询，jboss后台报异常日志，需要优化应用服务器打开文件数。详见：6.4其他负载测试
2． 需要优化程序war包数据连接数；
3． 需要优化数据库连接数，以oracle为例需要调整processes和sessions；
4． 需要对数据库查询优化
名称
30并发
40并发响
50并发
60并发混合
人员查询
5.086
6.371
8.一三3
4.069（50%）
团队查询
1.355
1.681
2.101
3.672（33%）
网点查询
2.988
3.509
4.832
3.266（17%）
由此可见，对数据量较大、关联较多的人员查询，系统响应时间相对较长。需要进行数据库查询优化。建议对现在系统中，用户UI中查询条件做为必选项的条件建立索引。

本次测试对系统设置做了以下调整，供参考。
1． 程序war包数据连接调整
Ø 找到war所在路径双击打开; 以10.1.110.237为例：/jboss/JBoss-4.2.2.GA/server/default/deploy/ CSMP_XINHUA.war
Ø 用文本编辑器打开配置文件: WEB-INF\classes\applicationContext.xml
Ø 找到以下节点
<property name="initialPoolSize" value="1" />
  <property name="minPoolSize" value="10" />
  <property name="maxPoolSize" value="50" />
Ø 修改value值完成war包连接池修改
initialPoolSize ：初始连接
minPoolSize：最小连接
maxPoolSize：最大连接
value修改原则：maxPoolSize不得大于oracle连接的sessions；最小连接，初始连接不得的大于最大连接。

2． oracle数据库连接调整
操作方法：
Ø 登录Linux客户端
Ø 以数据库管理员身份登录sqlplus
Ø 使用如下命令查看processes和sessions
show parameter processes
show parameter sessions
Ø 使用如下命令修改processes和sessions
alter system set processes=300 scope=spfile;
alter system set sessions=335 scope=spfile;
Ø processes和sessions数量应该满足：sessions=(1.1*process+5)

3． Oracle数据库磁盘空间已满，增加表空间数据文件
Ø 磁盘分区：
fdisk /dev/sda
Mkdisk –t ext3 /dev/sda6
Mkdir oracledata
Mount –t ext3 /dev/sda/ /oracledata/
Ø 数据库操作：
登录以数据库管理员身份登录sqlplus;
Alter tablespace user add datafile ‘/oracledata/user02.dbf’ size 6G autoextend on next 100M maxsize unlinted;

4． 修改Linux系统最大打开文件数（应用服务器）
打开linux终端，使用root登录
查看：ulimit –a
修改：ulimit –n 8096
7. 附件1：
建议升级配置

3.4.202507:4507:45:3025.3.47时45分7时45分30秒3月. 4, 254 三月 20257:45:30 上午07:45:30
2025年3月4日星期二07:45:30