XXX容灾系统性能测试
性能测试方案项目文档Page 1 of 14
文档资料信息
发送列表
版本历史
注意事项
内部传阅
项目文档XXX异地容灾Page 2 of 14
目录
1项目介绍 (5)
1.1测试背景 (5)
1.2测试目的 (5)
1.3参考文档 (5)
1.4缩略语和术语说明 (5)
2测试范围 (5)
2.1涉及系统 (6)
3压测环境搭建 (6)
3.1生产环境拓扑图 (6)
3.2压测环境拓扑图 (6)
3.3测试设备列表 (6)
3.4测试环境和生产环境差异 (6)
3.5性能测试机配置 (7)
3.6性能测试工具 (7)
4压测条件准备 (7)
4.1准备工作 (7)
5性能测试方案 (7)
5.1性能测试策略 (7)
5.2性能测试通过准则 (8)
5.3测试业务模型 (8)
5.4测试场景设计 (8)
5.4.1第一轮测试 (9)
5.4.2第二轮测试 (12)
5.5测试数据要求 (12)
5.6监控内容 (13)
项目文档XXX异地容灾Page 3 of 14
6测试计划 (13)
7团队 (13)
8风险 (14)
9通过标准 (14)
10优化建议 (14)
项目文档XXX异地容灾Page 4 of 14
1项目介绍
1.1测试背景
随着业务量和业务能力的拓展，为了防止XXX系统因事故无法使用，建立灾备系统
1.2测试目的
本次性能测试的目的是检测灾备系统的性能情况。
作为XXX的灾备系统，能够在事故发生后切换至灾备系统，能够稳定运行。
对该系统进行核心业务场景的性能测试。
希望在模拟生产环境的情况下，能够收集相应的系统参数，作为灾备系统评估的依据。
1.3参考文档
《XXX环境应用服务器列表清单》、《XXXdb清单v2》、《XXX环境网络拓扑图》
1.4缩略语和术语说明
性能测试：在一定约束条件下（指定的软件、硬件和网络环境等）确定系统所能承受的最大负载压力的测试过程。
场景：一种文件，用于根据性能要求定义在每一个测试会话运行期间发生的事件。
虚拟用户：在场景中，LoadRunner 用虚拟用户代替实际用户。
模拟实际用户的操作来使用应用程序。
一个场景可以包含几十、几百甚至几千个虚拟用户。
虚拟用户脚本：用于描述虚拟用户在场景中执行的操作。
事务：表示要度量的最终用户业务流程。
并发数：单位时间内同时执行一种操作的用户数量
在线用户数：访问被测应用的用户数量，单位时间内用户不会同时对被测服务器发送请求，产生压力TPS：Transaction Per Second，每秒事务数量，单位是事务/秒
TRT:Transaction Response Time，事务响应时间，指TPS稳定时的平均事务响应时间，单位是秒
2测试范围
XXX灾备系统
项目文档XXX Page 5 of 14
2.1涉及系统
XXX灾备系统
3性能测试环境搭建
3.1生产环境拓扑图
3.2性能测试环境拓扑图
3.3测试设备列表
应用服务器37台，配置如下：
CPU个数 16
CPU型号Intel(R)Xeon(R)******************
内存：82G
系统 Linux
数据库服务器1台，配置如下：
CPU个数 60
CPU型号Intel(R)Xeon(R)********************
内存：380G
系统 Linux
数据库ORACLE 11g
3.4测试环境和生产环境差异
按照最接近生产系统结构的原则，因只有两台数据库服务器，至少有一台参与性能测试，所以本次性能测试按照实际生产环境1:2比例缩小，也就是10台应用服务器，1台数据库服务器
项目文档XXX Page 6 of 14
因10台应用服务器对数据库服务器产生的压力太小，改为37台应用服务器和1台数据库服务器
3.5性能测试机配置
性能测试测试机1台，详情如下：
系统名称Microsoft® Windows Server® 2008 Enterprise
处理器Intel(R) Xeon(R) CPU E7- 4830 @ 2.13GHz，2134 Mhz，8 个内核，8 个逻辑处理器
内存16.0 GB
备注：压测机CPU使用率<50% 内存<80% IOBUSY<50% 磁盘使用率<90% 网络带宽<30%
3.6 性能测试工具
Loadrunner 11
4性能测试条件准备
4.1准备工作
1、测试功能点全部通过功能测试，确保功能上没有问题
2、准备性能测试环境服务器：
A、应用服务器10台
B、数据库服务器1台
3、准备性能测试机1台，需要安装Loadrunner 11并打通到应用服务器的网络
4、对于每个测试功能点，都要事先调试好相应脚本，并准备测试数据。
保证脚本能够成功回放，数据
正确
5、创建测试场景，配置好各场景设置
6、测试过程中保存好脚本及分析结果，并规范的对脚本和分析结果命名
5性能测试方案
5.1性能测试策略
1、关键资源不处于阻塞状态
A、服务器CPU利用率<70%
项目文档XXX Page 7 of 14
B、物理内存利用率<80%
C、场景通过率>99.99%
2、组合多个场景并发测试
3、测试执行
采用阶梯方式，并发数按照5、10、15、20….逐步增加，直至在某一个并发数增加后TPS达到峰值，并再增加并发造成响应时间增加，事件通过率降低
5.2性能测试通过准则
1、达到性能要求，在要求并发数用户下，系统响应时间小于或者等于客户要求的响应时间
2、在长时间运行后，系统不崩溃，各功能正常。
3、服务器CPU、内存、等参数保持稳定
4、测试停止后，一段时间内占用资源可以正常释放
5.3测试业务模型
以下根据生产环境（2016年6月26日当日按照工作10小时数据估算值TPS=并发数/平均响应时间=日交易量*0.8/7200）
5.4测试场景设计
1、员工登录
项目文档XXX Page 8 of 14
2、新建客户
5.4.1第一轮测试
5.4.1.1场景设置
员工登录
5.4.1.2测试结果
➢整体结果
项目文档XXX Page 9 of 14
➢基准测试虚拟用户数与TPS关系趋势图
➢基准测试虚拟用户数与处理时间关系趋势图
项目文档XXX Page 10 of 14
本次性能测试一共37台应用服务器，两台数据库服务器，压测30分钟
从压测图中可以看出，随着并发数增加（0-600）时间段（0:00-8:00）tps稳定上升，处理时间无太大变化
随着并发数增加（600-2500）时间段（8:00-15:00）TPS基本维持在2200—2300，处理时间随着并发数增加而增加
随着并发数增加（2500+）时间段（15:00-20:00）TPS呈现不规则跳动，处理时间也大幅度增加，同时错误事务数量变大，出现了接口异常和超时
因本次只压测了员工登录，门户部署的应用内存小于2.0G当TPS达到2300并发数最高为2500
5.4.2第二轮测试
5.4.2.1场景设置
新建客户
5.4.2.2测试结果
➢整体结果
XXX
➢基准测试虚拟用户数与TPS关系趋势图
XXX
➢基准测试虚拟用户数与处理时间关系趋势图
Xxx
5.5测试数据要求
客户设备号、员工工号及密码
测试数据需求列表
5.6监控内容6测试计划
7团队
容灾项目组
8风险
9 通过标准
1、性能测试场景通过，并满足并发、响应时间等要求
2、系统资源消耗
服务器CPU利用率<70%
物理内存利用率<80%
场景通过率>99.99%
3、性能测试结束后一段时间内，资源（系统资源及数据资源）释放正常
10 优化建议
XXX。