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