致远协同管理软件压力测试方案.docx

1、致远协同管理软件压力测试方案XX市政府协同项目压力测试报告北京致远协创软件有限公司2016-6-12第1章 前言 - 4 -1.1 文档说明 - 4 -第2章 测试目标 - 4 -第3章 术语和缩略词 - 5 -第4章 测试环境 - 6 -4.1 测试环境结构 - 6 -4.1.1测试环境 - 6 -4.2 测试工具 - 7 -第5章 测试范围及内容 - 8 -第6章 测试结果 - 8 -6.1 首页登录浏览测试用例及结果 - 8 -6.1.1测试结果 - 9 -6.1.2测试分析截图 - 9 -6.2 自由协同测试用例及结果 - 11 -6.2.1测试结果 - 11 -6.2.2测试分析截图

2、 - 12 -6.3 公告测试用例及结果 - 14 -6.3.1测试结果 - 14 -6.3.2测试分析截图 - 15 -6.4 表单流程测试用例及结果 - 16 -6.4.1测试结果 - 17 -6.4.2测试分析截图 - 18 -6.5 接口测试用例及结果 - 20 -6.5.1测试结果 - 20 -6.5.2测试分析截图 - 20 -6.6 综合场景测试结果 - 22 -6.6.1测试分析截图 - 22 -第7章 服务器监控情况 - 23 -第8章 测试分析及优化 - 24 -8.1 测试过程 - 24 -8.2 性能瓶颈分析 - 25 -8.3 性能提升建议 - 25 -8.4 数据库

3、服务器优化 - 26 -8.5 数据库服务器优化效果 - 26 -8.5.1概览 - 26 -8.5.2表单场景优化测试 - 27 -8.5.3小结 - 29 -第9章 测试总结 - 30 -第1章 前言1.1 文档说明本文档为致远协同管理软件在XX政府实际生产环境下的压力测试方案，通过获取每个场景在不同并发下的性能指标，为产品最终能支持的在线人数提供指导意见。本文档由北京致远协助软件有限公司顾问编写，需要相关领导审阅确认并签字。本文档为后续实施工作的重要依据，需要双方最终确认，如果需要更改或添加内容，则必须由双方共同协商。第2章 测试目标本文档是针对致远协同管理软件的功能完整性、高可靠性的集

4、群等多方面而进行的。其目的主要是验证系统在XX政府实际生产环境下是否有能力承受高并发登录系统进行相关事务处理，发现现有系统环境中可能存在的性能方面问题，提出可行性建议，以尽可能降低后续工作风险，为系统的稳定运行提供保证。主要测试目标如下：1、获得协同系统的性能表现，为系统上线提供依据。2、考查协同系统的并发性和效率情况，为优化提供指导。3、获得系统性能较优的参数配置，为协同系统调优提供依据。4、获得协同系统在不同负载下的主机资源消耗情况，为硬件配置提供依据。第3章 术语和缩略词术语/缩略词说明 Transaction、事务事务用来衡量脚本中一行代码或多行代码的执行所耗费的时间。成功总事务数场景

5、运行期间成功的总事务数。Average平均响应时间,是指所有用户的系统响应时间的平均值。90 Percent90%响应时间,是指90%的用户在此时间内完成操作的响应。思考时间用户操作过程中的延迟，在测试时分两种情况，取消思考时间和不取消思考时间；当取消了思考时间，增加了压力，测试过程中更接近于并发访问；不取消思考时间，测试过程更接近于真实的环境。系统响应时间系统响应时间是指应用系统从请求发出开始到客户端接收到所有数据所消耗的时间。用户对响应时间容忍度指标容忍范围数据查看数据处理反应迅速=3秒6秒有顿挫感8秒12秒反应慢15秒20秒宕机120秒120秒第4章 测试环境4.1 测试环境结构测试环境

6、由负载生成器/性能监视器生成虚拟操作，通过内网生成相关数据模拟用户真实操作。4.1.1 4.1.1测试环境服务器硬件环境：类型配置信息数量备注应用服务器CPU：Intel Xeon E5-26703台应用服务器集群部署内存：64G硬盘：600G*2 RAID 1数据库服务器CPU：Intel Xeon E5-26501台内存：64G硬盘：600G*2 RAID 1服务器软件环境：类型说明软件版本数据库服务器操作系统：Centos Linux 6.4数据库：Oracle 11g R2 11.2.0.4 Linux x86-x64应用服务器操作系统：Centos Linux 6.4应用服务器：致远

7、A8-V5协同软件 v5.6集团版备注：4.2 测试工具LoadRunner 11使用HTTP/HTTPS协议。主要思想是使用虚拟用户（Virtual users）来模拟实际用户对系统施加压力。LoadRunner 使用虚拟用户来最小化测试的硬件和人员需求。虚拟用户是一个代理，它模拟真实的用户来测试程序。通过使用虚拟用户生成器，用户可以生成虚拟用户。在生成虚拟用户后，用户可以定义压力场景了-这是业务操作和虚拟用户数量的结合。LoadRunner 采用了可视化控制器 一个交互的环境来组织、驱动和管理压力测试的场景。控制器通过驱动和同步真实应用和多个并发用户来执行测试。第5章 测试范围及内容序号模

8、块/功能备注1登录、首页2自由协同3公告4表单、流程5OA回写外部系统，外部系统触发OA接口测试第6章 测试结果6.1 首页登录浏览测试用例及结果脚本名称Protal操作步骤压力策略：分别通过200、400、500用户加压执行动作1初始化协同登陆地址2初始化登陆用户3提交登陆请求4验证进入首页5浏览系统菜单6登出结束6.1.1 6.1.1测试结果事务/指标Transaction个人首页默认栏目相关业务200400500AVG (s)登录0.2190.4720.563登录+个人空间2.2043.5794.7966.1.2 6.1.2测试分析截图200用户400用户500用户6.2 自由协同测试用

9、例及结果脚本名称Col操作步骤压力策略：分别通过300、400、500用户加压执行动作1初始化协同登陆地址2初始化登陆用户3提交登陆请求4验证进入首页5打开新建事项6编辑流程7编辑正文8发送协同9查看已发列表10查看待办事项列表11处理协同12登出结束6.2.1 6.2.1测试结果事务/指标Transaction自由协同相关业务300400500AVG (s)新建协同0.0460.0690.048发送协同0.3611.0422.086已发列表0.0660.1580.314待办列表0.160.5861.415查看协同0.3681.1581.78处理协同0.2560.5831.388已办列表0.0

10、70.1540.3566.2.2 6.2.2测试分析截图300用户400用户500用户6.3 公告测试用例及结果脚本名称Bul操作步骤压力策略：分别通过300、400用户加压执行动作1初始化协同登陆地址2初始化登陆用户3提交登陆请求4验证进入首页5打开新建公告6编辑公告内容7选择发送人员8发送9查看公告10保持在线30s11登出结束6.3.1 6.3.1测试结果事务/指标Transaction公告相关业务300400AVG (s)发送公告0.2310.272公告板块列表0.7941.255公告列表4.6298.404查看公告0.0660.0856.3.2 6.3.2测试分析截图300用户400

11、用户6.4 表单流程测试用例及结果脚本名称Form操作步骤压力策略：分别通过300、400、500用户加压执行动作1初始化协同登陆地址2初始化登陆用户3提交登陆请求4验证进入首页5调用表单模板6编辑内容7发送8查看已发列表9查看代办事项列表10处理表单11登出结束6.4.1 6.4.1测试结果事务/指标Transaction表单流程相关业务300400500AVG (s)新建表单4.0242.0950.918发送表单2.7152.2051.825已发列表0.4190.2210.04查看表单2.0971.0540.55处理表单5.3793.52536.4.2 6.4.2测试分析截图300用户40

12、0用户500用户6.5 接口测试用例及结果脚本名称rest操作步骤压力策略：分别通过100、300、500用户加压执行动作1调用接口发起表单结束6.5.1 6.5.1测试结果事务/指标Transaction接口相关业务100300500AVG (s)触发表单0.0270.0690.1586.5.2 6.5.2测试分析截图100用户300用户500用户6.6 综合场景测试结果脚本名称Union5.0（综合场景）操作步骤压力策略：以400用户加压场景组合1登录首页2自由协同事务3公告事务4表单事务结束6.6.1 6.6.1测试分析截图第7章 服务器监控情况用例用户数应用服务器（平均值）数据库服务器

13、（平均值）CPU%内存剩余磁盘busyCPU%内存剩余磁盘busy首页门户2008.3%60%0.1%1.7%14%0.6%40010.7%58%0.1%2.3%12%0.7%50011.6%55%0.1%2.6%10%1.1%协同30015%54%0.1%57.7%0.9%40%4006.4%53%0.1%60%0.7%56.9%5003.6%52%0.1%30.4%0.6%86.7%公告3003%57%0.1%52.5%1.6%72%4001.5%56%0.1%56.2%0.8%80%表单30010.8%44%0.1%2.8%0.1%17.8%40012.8%40%0.1%3.8%0.1%

14、40.1%50012.9%38%0.1%9.6%0.05%82.8%接口10013.7%57%2.9%7%0.9%58.2%30012.2%55%2.6%6.9%0.047%41.9%5005%54%1.1%3.5%0.06%33.8%综合40013.6%40%0.1%11.6%0.1%28.7%第8章 测试分析及优化8.1 测试过程在测试过程中，除公告和综合场景外，均完成最大500用户的运行测试。对于公告场景实际情况不存在大量用户同时发起公告的情况。在测试进行过程中，对于应用的产品参数，做了适当的调整，以达到优化的目的，通过实际测试，验证了优化效果。如：表单事务，500用户的测试数据好于40

15、0用户数据。通过此次测试的过程，和不断调整参数的过程，已经将应用服务的各项参数调整至最优状态。8.2 性能瓶颈分析通过测试最终得出的服务器数据，可以看出，无论任何场景下，数据库服务器的瓶颈凸显。在多种较多数据处理及查看的场景下，内存几乎耗尽，进而频繁调用swap分区来进行弥补，同时硬盘I/O带宽已被几乎占满，CPU利用率也伴随上升，影响系统性能发挥由于Oracle数据需要占用的内存较多，且对于swap分区有最小要求。系统默认给定的swap分区只有8G，而Oracle需要至少16G空间，所以只能进行文件挂载。8.3 性能提升建议目前数据库服务器为Oracle单应用数据库，建议后续采用RAC集群方

16、案，既能分担服务器压力，同时能增强数据库的可用性。就目前情况，建议可用调整Oracle连接占用内存，其他参数优化。8.4 数据库服务器优化根据实测情况观察，数据库服务器内存消耗非常大，当内存几乎耗尽时即开始使用swap分区，同时CPU、磁盘使用率开始明显上升，甚至达到100%的情况。经查询相关内存数据，决定通过启用大页（hugepages）管理，减少内存管理开销，避免swap引发的数据库性能问题。具体优化部署如下：（1）关闭Oracle Database 11g中的AMM（本服务器中默认就为关闭状态，未调整）（2）计算hugepages大小，通过脚本得到hugepages=20492（3）修改

17、内核参数/etc/sysctl.conf ，加入hugepages=20492，并执行生效（4）设定Oracle内存锁 即/etc/security/limits.conf 文件中加入Oracle memlock（5）重启数据库8.5 数据库服务器优化效果通过优化后，重新进行的几个场景测试，以验证优化效果。8.5.1 8.5.1概览 使用门户场景进行加压，观察数据库服务器情况，初始500用户，随后瞬间加压至1100用户。通过运行观察，未出现错误事务及报错信息，服务器的内存保持平稳，未出现快速消耗情况，同时，CPU与磁盘状态正常，未出现高占用情况。由此可初步判断，优化的目的达到。8.5.2 8.

18、5.2表单场景优化测试优化后测试结果可以看出，较之前的测试有较大的提升，在用户翻倍的情况，AVG未超过0.2秒服务器资源情况对比：from-500为优化前500用户场景，fromnew为优化后1100用户场景CPU情况：内存情况：硬盘情况：8.5.3 8.5.3小结经过多项测试，优化后服务器性能提升明显，同时对于整体OA应用测试结果都有较大幅度提升，可以验证之前性能瓶颈的判断。通过寻找瓶颈，优化瓶颈，进而提升整体应用性能，也是此次压力测试的目标之一。通过此次应用及数据库服务器的调整，达成的系统优化的目标。第9章 测试总结通过此次测试，在500用户情况下，系统在各方面的响应及运行指标均保持在正常范围内，未出现宕机等其他异常情况。按照经验，在进行压力测试的用户数与实际用户数的比例为1:10，即500用户相当于理论实际情况下的5000用户。从此次并发测试的结果来看，平台可以满足5000人在线的需求。对于高事务并发的情况下，数据库服务器压力较大。此次通过测试对数据库服务器进行了一定优化，但强烈建议后续一定要采取RAC方案，提升性能的同时增强安全性。目前平台经过测试验证，可以满足系统现有应用需求。