北京农商银行新一代综合柜面业务系统性能测试报告1

北京农商银行新一代综合柜面业务系统性能测试报告1

新一代综合柜面业务系统

性能测试报告

修订记录

测试简介

项目背景

为解决原有字符终端柜面系统不能处理非线性数据（如图像）的缺陷、解决业务中的柜员离柜咨询题，并对交易前端的功能性梳理和整合，北京农商银行将实施现有字符终端向图形终端的改造，实施新一代综合柜面业务系统项目。

在新一代综合柜面业务系统全面推广上线前，需要对新系统平台进行性能测试，猎取系统的并发处理能力、交易响应时刻等性能指标。

测试目标

此次性能测试的测试目标为：

猎取新一代综合柜面业务系统在测试环境中的性能指标数据

发觉性能瓶颈，协助开发人员进行性能调优，对系统上线提供性能建议和评估

测试范畴

新一代综合柜面系统的架构示意图如下图所示，图中红线虚框为此次性能测试的范畴，包括ABS处理平台的后台应用服务器和数据库服务器。

性能测试指标要求

测试方案

压力模型

此次性能测试采纳如下的简易压力模型：

通过LoadRunner模拟图形终端各柜员向ABS平台发起交易压力

通过测试环境中的核心业务系统响应柜面交易要求

交易选择

按照和开发组的沟通，选择如下前端处理比较复杂的典型交易：

测试脚本

按照上述的系统架构示意图，通过LoadRunner的Socket协议录制柜面前端向柜面系统应用服务器发起的柜面交易，发觉Socket交互次数（一组send和receive算一次交互）专门多（0210交易51次Socket交互），而且脚本回放时报接收报文长度不匹配错误。

新柜面系统开发组提供了一个测试用的Jar包，将图形前端ABC和后台应用服务器ABS之间的通讯过程进行了封装，通过解析描述型的交易数据文件后向后台提交交易，为此，使用LoadRunner的Java协议，测试脚本中通过调用Jar包中的对象提交柜面交易。使用此测试脚本方案临时也有如下缺点：

无法实现交易数据的参数化

脚本中只能定义各柜面交易执行全过程的长事务，无法对交易中各时期进行分解分析（例如页面控件响应时刻、交易提交响应时刻、打印响应时刻等）

测试脚本中无法猎取交易执行结果：交易提交后不返回响应特点码，从测试脚本中无法判定交易执行的情形，需要分析后台日志文件或数据库流水表分析交易是否成功（性能测试交易量庞大可能会引起大量的交易结果分析工作量）

LoadRunner统计分析数据失真（因失败交易也当成成功交易进行统一分析）

资源监控

按照压力测试模型，此次性能测试需要监控如下主机的一些性能指标数据：

新柜面系统应用服务器主机（Linux操作系统）

CPU – CPU Utilization（CPU使用率%）

Memory – Paging rate（内存页交换速率）

I/O – Disk Traffic（磁盘交换速率）

新柜面系统数据库服务器主机（AIX操作系统）

CPU – CPU Utilization（CPU使用率%）

Memory – Paging rate（内存页交换速率）

I/O – Disk Traffic（磁盘交换速率）

LoadRunner操纵器和压力产生器主机（Windows XP操作系统）

CPU– % Total Processor Time（总的CPU使用率）

Memory – Available Mbytes（物理内存的可用数，单位 Mbytes）

Memory – Page Faults/sec（页面错误导致的页交换计数）

I/O – %Disk Time（磁盘驱动器读写要求已用时刻所占百分比）

主机资源指标数据监控的方法：

优先通过LoadRunner进行监控

通过操作系统内部指令（如top、vmstat等）

测试场景

设计如下类型的测试场景：

基准测试：猎取系统处理各典型交易在无压力情形下单笔交易的耗时，为并发场景提供一个差不多数据参考。

并发测试：检验服务器端对每个典型交易多个并发用户的处理能力，猎取系统处理性能指标值。

各测试场景设置信息如下：

注：按照全行柜面终端数约2800的统计数据，最大并发数为终端数的10%～15%（体会值），选择最大300并发的场景。

测试环境

网络拓扑图

此次性能测试环境的网络拓扑图如下：（其中核心系统使用测试环境中的172.16.12.6主机）

软硬件配置

测试工具

测试实施情形

测试时刻和地点

时刻： 2011年10月08日 — 2011年10月21日

地点： 北京农商银行空港办公区3楼测试机房

参加测试人员

参加此次性能测试的人员包括：

王 鹏：测试经理，性能测试总体和谐

高 伟：开发组支持，测试脚本录制和调试

王晓华：性能测试专家，制订方案、指导测试

王时磊：性能测试工程师，测试工具、测试场景预备、测试执行

测试实施进度

测试结果

基准测试

测试结果

使用测试工具LoadRunner运行测试脚本，统计出测试结果如下（TPS、ART、CPU%均为平均值）：

在无压力的情形下，0210（个人客户信息建立）的平均交易响应时刻为418ms，其中该交易包括如下完整的交易处理过程（可参见附录2中0210交易处理脚本）：

输入交易码后，猎取Frame框架显示内容

各输入场输入数据时与后台系统的交互

提交交易，猎取核心系统返回结果

分析图表

测试工具LoadRunner Analysis的TPS图表：

测试工具LoadRunner Analysis的ART图表：

并发测试

测试结果

使用测试工具LoadRunner运行测试脚本，统计出测试结果如下（TPS、ART、CPU%均为平均值）：

在并发场景时，显现了如下两种交易失败导致交易成功率不高：

并发数达到50时，ABS交易流水表显现记录状态为"x"的记录（未收到核心系统对交易的处理结果），并发数为10、20、30、40时差不多正常

并发数达到100及以上时，ABS交易流水表中记录数小于LoadRunner 中记录的实际发送的交易笔数（部分交易数据丢失，未发往核心系统）

另外，从表中能够看出：

在当前测试环境配置下，新柜面系统的最大处理能力约为40tps

在50并发时，0210交易的平均交易响应时刻为1.452秒

在各并发场景下，应用服务器和数据库服务器的CPU占用率均不高

分析图表

场景BF_0210_10_10m结果分析图

1)交易吞吐量TPS-虚拟用户数量VU合并曲线

2)交易响应时刻ART-虚拟用户数量VU合并曲线

3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线

4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线

场景BF_0210_20_10m结果分析图

1)交易吞吐量TPS-虚拟用户数量VU合并曲线

2)交易响应时刻ART-虚拟用户数量VU合并曲线

3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线

4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线

场景BF_0210_30_10m结果分析图

1)交易吞吐量TPS-虚拟用户数量VU合并曲线

2)交易响应时刻ART-虚拟用户数量VU合并曲线

3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线

4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线

场景BF_0210_40_10m结果分析图

1)交易吞吐量TPS-虚拟用户数量VU合并曲线

2)交易响应时刻ART-虚拟用户数量VU合并曲线

3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线

4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线

场景BF_0210_50_10m结果分析图

1)交易吞吐量TPS-虚拟用户数量VU合并曲线

2)交易响应时刻ART-虚拟用户数量VU合并曲线

3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线

4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线

场景BF_0210_100_10m结果分析图

1)交易吞吐量TPS-虚拟用户数量VU合并曲线

2)交易响应时刻ART-虚拟用户数量VU合并曲线

3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线

4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线

场景BF_0210_150_10m结果分析图

1)交易吞吐量TPS-虚拟用户数量VU合并曲线

2)交易响应时刻ART-虚拟用户数量VU合并曲线

3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线

4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线

场景BF_0210_200_10m结果分析图

1)交易吞吐量TPS-虚拟用户数量VU合并曲线

2)交易响应时刻ART-虚拟用户数量VU合并曲线

3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线

4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线

场景BF_0210_250_10m结果分析图

1)交易吞吐量TPS-虚拟用户数量VU合并曲线

2)交易响应时刻ART-虚拟用户数量VU合并曲线

3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线

4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线

场景BF_0210_300_10m结果分析图

1)交易吞吐量TPS-虚拟用户数量VU合并曲线

2)交易响应时刻ART-虚拟用户数量VU合并曲线

3)应用服务器主机CPU占用率-虚拟用户数量VU合并曲线

4)数据库服务器主机CPU占用率-虚拟用户数量VU合并曲线

数据分析

对并发场景，按照不同并发数对要紧性能指标（TPS、ART、CPU%）进行图表分析如下：

从图中能够看出：

随着并发用户数增加，TPS缓慢增加。当并发数为250时，TPS达到最大值，约为40tps。

随着并发用户数增加，ART也随之增加。当并发数大于50时，平均交易响应时刻超过2秒的最佳用户体验值。

在各并发场景中，应用服务器和数据库服务器的CPU占用率均不高，表明主机硬件配置临时还可不能成为系统瓶颈。

系统评判

通过在此次性能测试环境中对新一代柜面系统的性能评测，可得到如下基础结论：

新柜面系统在50个以上的并发用户数时均显现较多的交易失败（失败类型包括未收到核心处理结果及交易要求未发往核心系统），新柜面系统在此次测试环境中支持的最大并发数约为40。

当前测试环境下，新柜面系统支持的最大交易处理能力约为40tps，且应用服务器和数据库服务器CPU占用率均不超过25%

在小于50个并发时，平均交易响应约为1.5秒，在最佳用户体验值范畴内。

测试遗留咨询题

因测试脚本、测试环境、测试支持等方面的限制，此次性能测试遗留有一些咨询题留待以后合适的时刻进行解决：

测试环境与生产环境的硬件配置有差异（如生产环境应用服务器有负载均衡设备），导致当前测试结果仅能提供一些参考。

受测试脚本、挡板程序开发进度的限制，此次性能测试仅选择一个0210典型交易，无法执行更能模拟生产情形的混合业务场景。

稳固性场景也需要在混合场景的基础上进行长时刻的测试执行，以考察新一代柜面系统提供连续服务的能力。

脚本无法进行参数化，网点开门时柜面并发登录的场景暂无法模拟，也无法获得系统支持的最大连接柜员数

达到50个并发后显现大量的交易失败，需要开发组定位咨询题缘故，修改后再进行回来验证

在达到最大tps时，服务器CPU占用率并不高，系统瓶颈还需要和开发组进行分析验证

附录

性能测试记录表

0210交易处理脚本

本文来源：https://www.2haoxitong.net/k/doc/604a2692d35abe23482fb4daa58da0116d171f44.html