致远协同管理软件压力测试方案Word文件下载.docx
《致远协同管理软件压力测试方案Word文件下载.docx》由会员分享，可在线阅读，更多相关《致远协同管理软件压力测试方案Word文件下载.docx（26页珍藏版）》请在冰豆网上搜索。
8.5.3小结-29-
第9章测试总结-30-
第1章前言
1.1文档说明
本文档为致远协同管理软件在XX政府实际生产环境下的压力测试方案，通过获取每个场景在不同并发下的性能指标，为产品最终能支持的在线人数提供指导意见。
本文档由北京致远协助软件有限公司顾问编写，需要相关领导审阅确认并签字。
本文档为后续实施工作的重要依据，需要双方最终确认，如果需要更改或添加内容，则必须由双方共同协商。
第2章测试目标
本文档是针对致远协同管理软件的功能完整性、高可靠性的集群等多方面而进行的。
其目的主要是验证系统在XX政府实际生产环境下是否有能力承受高并发登录系统进行相关事务处理，发现现有系统环境中可能存在的性能方面问题，提出可行性建议，以尽可能降低后续工作风险，为系统的稳定运行提供保证。
主要测试目标如下：
1、获得协同系统的性能表现，为系统上线提供依据。
2、考查协同系统的并发性和效率情况，为优化提供指导。
3、获得系统性能较优的参数配置，为协同系统调优提供依据。
4、获得协同系统在不同负载下的主机资源消耗情况，为硬件配置提供依据。
第3章术语和缩略词
术语/缩略词
说明
Transaction、事务
事务用来衡量脚本中一行代码或多行代码的执行所耗费的时间。
成功总事务数
场景运行期间成功的总事务数。
Average
平均响应时间,是指所有用户的系统响应时间的平均值。
90Percent
90%响应时间,是指90%的用户在此时间内完成操作的响应。
思考时间
用户操作过程中的延迟，在测试时分两种情况，取消思考时间和不取消思考时间；
当取消了思考时间，增加了压力，测试过程中更接近于并发访问；
不取消思考时间，测试过程更接近于真实的环境。
系统响应时间
系统响应时间是指应用系统从请求发出开始到客户端接收到所有数据所消耗的时间。
用户对响应时间容忍度指标
容忍范围
数据查看
数据处理
反应迅速
<
=3秒
6秒
有顿挫感
8秒
12秒
反应慢
15秒
20秒
宕机
120秒
第4章测试环境
4.1测试环境结构
测试环境由负载生成器/性能监视器生成虚拟操作，通过内网生成相关数据模拟用户真实操作。
4.1.14.1.1测试环境
服务器硬件环境：
类型
配置信息
数量
备注
应用服务器
CPU：
IntelXeonE5-2670
3台
应用服务器集群部署
内存：
64G
硬盘：
600G*2RAID1
数据库服务器
IntelXeonE5-2650
1台
服务器软件环境：
说明
软件版本
操作系统：
CentosLinux6.4
数据库：
Oracle11gR211.2.0.4Linuxx86-x64
应用服务器：
致远A8-V5协同软件v5.6集团版
备注：
4.2测试工具
LoadRunner11使用HTTP/HTTPS协议。
主要思想是使用虚拟用户（Virtualusers）来模拟实际用户对系统施加压力。
LoadRunner使用虚拟用户来最小化测试的硬件和人员需求。
虚拟用户是一个代理，它模拟真实的用户来测试程序。
通过使用虚拟用户生成器，用户可以生成虚拟用户。
在生成虚拟用户后，用户可以定义压力场景了-这是业务操作和虚拟用户数量的结合。
LoadRunner采用了可视化控制器–一个交互的环境来组织、驱动和管理压力测试的场景。
控制器通过驱动和同步真实应用和多个并发用户来执行测试。
第5章测试范围及内容
序号
模块/功能
1
登录、首页
2
自由协同
3
公告
4
表单、流程
5
OA回写外部系统，外部系统触发OA
接口测试
第6章测试结果
6.1首页登录浏览测试用例及结果
脚本名称
Protal
操作步骤
压力策略：
分别通过200、400、500用户加压
执行动作
初始化协同登陆地址
初始化登陆用户
提交登陆请求
验证进入首页
浏览系统菜单
6
登出
结束
6.1.16.1.1测试结果
事务/指标
Transaction
个人首页默认栏目相关业务
200
400
500
AVG（s）
登录
0.219
0.472
0.563
登录+个人空间
2.204
3.579
4.796
6.1.26.1.2测试分析截图
200用户
400用户
500用户
6.2自由协同测试用例及结果
Col
分别通过300、400、500用户加压
打开新建事项
编辑流程
7
编辑正文
8
发送协同
9
查看已发列表
10
查看待办事项列表
11
处理协同
12
6.2.16.2.1测试结果
自由协同相关业务
300
新建协同
0.046
0.069
0.048
0.361
1.042
2.086
已发列表
0.066
0.158
0.314
待办列表
0.16
0.586
1.415
查看协同
0.368
1.158
1.78
0.256
0.583
1.388
已办列表
0.07
0.154
0.356
6.2.26.2.2测试分析截图
300用户
6.3公告测试用例及结果
Bul
分别通过300、400用户加压
打开新建公告
编辑公告内容
选择发送人员
发送
查看公告
保持在线30s
6.3.16.3.1测试结果
公告相关业务
发送公告
0.231
0.272
公告板块列表
0.794
1.255
公告列表
4.629
8.404
0.085
6.3.26.3.2测试分析截图
6.4表单流程测试用例及结果
Form
调用表单模板
编辑内容
查看代办事项列表
处理表单
6.4.16.4.1测试结果
表单流程相关业务
新建表单
4.024
2.095
0.918
发送表单
2.715
2.205
1.825
0.419
0.221
0.04
查看表单
2.097
1.054
0.55
5.379
3.525
6.4.26.4.2测试分析截图
6.5接口测试用例及结果
rest
分别通过100、300、500用户加压
调用接口发起表单
6.5.16.5.1测试结果
接口相关业务
100
触发表单
0.027
6.5.26.5.2测试分析截图
100用户
6.6综合场景测试结果
Union5.0（综合场景）
以400用户加压
场景组合
登录首页
自由协同事务
公告事务
表单事务
6.6.16.6.1测试分析截图
第7章服务器监控情况
用例
用户数
应用服务器（平均值）
数据库服务器（平均值）
CPU%
内存剩余
磁盘busy
首页门户
8.3%
60%
0.1%
1.7%
14%
0.6%
10.7%
58%
2.3%
12%
0.7%
11.6%
55%
2.6%
10%
1.1%
协同
15%
54%
57.7%
0.9%
40%
6.4%
53%
56.9%
3.6%
52%
30.4%
86.7%
3%
57%
52.5%
1.6%
72%
1.5%
56%
56.2%
0.8%
80%
表单
10.8%
44%
2.8%
17.8%
12.8%
3.8%
40.1%
12.9%
38%
9.6%
0.05%
82.8%
接口
13.7%
2.9%
7%
58.2%
12.2%
6.9%
0.047%
41.9%
5%
3.5%
0.06%
33.8%
综合
13.6%
28.7%
第8章测试分析及优化
8.1测试过程
在测试过程中，除公告和综合场景外，均完成最大500用户的运行测试。
对于公告场景实际情况不存在大量用户同时发起公告的情况。
在测试进行过程中，对于应用的产品参数，做了适当的调整，以达到优化的目的，通过实际测试，验证了优化效果。
如：
表单事务，500用户的测试数据好于400用户数据。
通过此次测试的过程，和不断调整参数的过程，已经将应用服务的各项参数调整至最优状态。
8.2性能瓶颈分析
通过测试最终得出的服务器数据，可以看出，无论任何场景下，数据库服务器的瓶颈凸显。
在多种较多数据处理及查看的场景下，内存几乎耗尽，进而频繁调用swap分区来进行弥补，同时硬盘I/O带宽已被几乎占满，CPU利用率也伴随上升，影响系统性能发挥
由于Oracle数据需要占用的内存较多，且对于swap分区有最小要求。
系统默认给定的swap分区只有8G，而Oracle需要至少16G空间，所以只能进行文件挂载。
8.3性能提升建议
目前数据库服务器为Oracle单应用数据库，建议后续采用RAC集群方案，既能分担服务器压力，同时能增强数据库的可用性。
就目前情况，建议可用调整Oracle连接占用内存，其他参数优化。
8.4数据库服务器优化
根据实测情况观察，数据库服务器内存消耗非常大，当内存几乎耗尽时即开始使用swap分区，同时CPU、磁盘使用率开始明显上升，甚至达到100%的情况。
经查询相关内存数据，决定通过启用大页（hugepages）管理，减少内存管理开销，避免swap引发的数据库性能问题。
具体优化部署如下：
（1）关闭OracleDatabase11g中的AMM（本服务器中默认就为关闭状态，未调整）
（2）计算hugepages大小，通过脚本得到hugepages=20492
（3）修改内核参数/etc/sysctl.conf，加入hugepages=20492，并执行生效
（4）设定Oracle内存锁即/etc/security/limits.conf文件中加入Oraclememlock
（5）重启数据库
8.5数据库服务器优化效果
通过优化后，重新进行的几个场景测试，以验证优化效果。
8.5.18.5.1概览
使用门户场景进行加压，观察数据库服务器情况，初始500用户，随后瞬间加压至1100用户。
通过运行观察，未出现错误事务及报错信息，服务器的内存保持平稳，未出现快速消耗情况，同时，CPU与磁盘状态正常，未出现高占用情况。
由此可初步判断，优化的目的达到。
8.5.28.5.2表单场景优化测试
优化后测试结果可以看出，较之前的测试有较大的提升，在用户翻倍的情况，AVG未超过0.2秒
服务器资源情况对比：
from-500为优化前500用户场景，fromnew为优化后1100用户场景
CPU情况：
内存情况：
硬盘情况：
8.5.38.5.3小结
经过多项测试，优化后服务器性能提升明显，同时对于整体OA应用测试结果都有较大幅度提升，可以验证之前性能瓶颈的判断。
通过寻找瓶颈，优化瓶颈，进而提升整体应用性能，也是此次压力测试的目标之一。
通过此次应用及数据库服务器的调整，达成的系统优化的目标。
第9章测试总结
通过此次测试，在500用户情况下，系统在各方面的响应及运行指标均保持在正常范围内，未出现宕机等其他异常情况。
按照经验，在进行压力测试的用户数与实际用户数的比例为1:
10，即500用户相当于理论实际情况下的5000用户。
从此次并发测试的结果来看，平台可以满足5000人在线的需求。
对于高事务并发的情况下，数据库服务器压力较大。
此次通过测试对数据库服务器进行了一定优化，但强烈建议后续一定要采取RAC方案，提升性能的同时增强安全性。
目前平台经过测试验证，可以满足系统现有应用需求。
升级会员 