性能测试报告 V1.1

秘密张良友说明： 1. 本文件中“”中内容为举例和说明文字，请在文件拟制时替换或删除；2. 若文中某章节内容可省略、不需要或适用，请保留该标题，并根据实际在内容部分写明“略”、“勿需”或“不适用”等，同时适当说明原因。3. 请作者注意在文档右上角修改该文档的密级。一帐通卡性能测试报告文件修订历史修订时间修订概要作者审核批准2009-12-10新建张良友模板修订历史版本生效时间变更概要作者审核批准第 3 页 共 25 页 秘密目录1.概述51.1背景51.2目标51.3范围51.3.1业务范围51.3.2系统范围51.4术语和缩略语52.测试内容及测试方法62.1测试内容62.2测试方法62.2.1性能测试流程62.2.2性能测试模型分析72.2.3评估测试和性能管理方案的规划实施82.3工作目标83.测试环境83.1测试环境拓扑图83.2测试环境配置93.3测试工具及监控工具部署104.测试场景104.1基准测试场景114.2单交易场景114.3单系统场景124.4疲劳测试场景124.5混合交易场景135.角色和职责136.性能测试总体报告146.1单业务场景性能分析146.1.1KISS系统交易分析146.1.2IST交易分析156.1.3ESB交易性能分析166.2综合业务场景性能分析166.2.1系统吞吐量TPS分析176.2.2交易响应时间分析186.2.3系统资源分析197.问题和建议217.1问题一217.2问题二227.3问题三227.4问题四227.5问题五238.附录231. 概述本文档为XX银行XX系统性能测试方案，其内容用于描述本次性能测试服务的实施方案，以及测试项目组织实施的技术规范。本文档中描述的内容，旨在 为XX系统的性能状态进行客观评估，提供性能数据； 为性能测试工作规定有效、完整的实施方案； 为性能测试工作规定具体的任务、角色分工、进度计划上的安排；1.1 背景满足集团的“一个客户，一个账户，多个产品，多种服务”的战略,XX将以标准的金融卡为基础，加载其他产品服务, XX卡与其它非银行产品的关联，将通过现有集团客户信息管理系统（CIF2）关联。 系统要上线前对XX系统做性能检验和评估。1.2 目标要求系统能支持并满足目前AS/400主机、信用卡系统的最大发卡量（4500万）及交易性能指标，不影响系统整体的交易性能。电话银行IVR及人工客服能支持最大发卡量的服务。程序没有大的性能漏洞；系统性能能够满足基本上线要求1.3 范围1.3.1 业务范围XX业务1.3.2 系统范围XX银行业务处理系统XX接入平台系统 XX业务受理系统1.4 术语和缩略语术语/缩略词说明响应时间TPSIST2. 测试内容及测试方法此次压力测试实施是对XXXX 系统性能进行测试评估的过程，我们将依据系统（生产环境）的实际运行现状，抽取对系统性能产生较大影响的业务交易，模拟最终用户的操作行为，构建一个与生产实际相近的压力仿真模型（场景），对系统实施压力测试，以此评判系统的整体性能的实际性能表现。2.1 测试内容根据与相关人员的沟通和交流，此期工程上线的目标和期限，通过对现有系统运行数据的统计，结合系统的设计目标和业务特点，遵循着发生频率高、对系统或数据库性能影响大、关键和核心业务等原则，本期测试内容重点为银联交易操作及ESB验密功能，以及后台批处理业务。2.2 测试方法此次压力测试通过构建与真实环境相同数据规模的压力测试环境，采用业界成熟的自动化性能测试工具Loadrunner，通过创建压力测试程序、构建压力测试模型，对被测试系统实施自动化压力测试，最后形成压力测试结果分析报告。2.2.1 性能测试流程通过自动化测试工具模拟最终用户向服务器发起业务请求，进行性能测试。通过测试工具对测试过程中系统各点进行监控，每一次测试结束后工具自动生成结果报告供分析使用。2.2.2 性能测试模型分析 系统是否能够稳定运行具有重要意义。因此，必须要采取科学的方法对XX系统进行全面的性能验收测试。 XX系统的性能测试模型分析应当按照下面几个步骤来实施： 业务模型建立分析XX系统上线后所面临的性能压力的来源和类别，并且通过分析历史交易数据来确定各种性能在整个系统压力所占比例。例如确定前台应用子系统的业务类别和并发比例，后台自动批处理的数据数量和类别等。最终目的是建立一个能够逼真模拟帐户管理系统实际运行场景的业务模型。 测试数据模型建立根据业务模型准备测试数据和基础数据，确保系统数据库中数据容量和真实性符合实际运行情况。 监控模型建立性能测试的目的不仅仅是获得关键业务的性能指标，同时也要通过性能测试监控主机、数据库、中间件的各个性能指标，从而发现性能瓶颈，为进一步的性能调优提供准确的参考数据。 测试模型建立对帐户管理系统的测试，因该采取基准测试、单业务负载测试、混合负载测试的顺序来执行。这样做的好处，在单业务负载测试是就可以发现各个系统本身的性能缺陷，而混合负责测试时将重点检查各个业务相互影响导致的性能缺陷。 执行模型建立XX系统的性能测试要测试人员、开发人员和运维人员紧密配合，才能保证整个测试工作的成功。因此，只有建立一套规范的性能测试流程，明确各个角色的工作职责，才能使性能测试工作有序、高效的开展。 风险模型建立由于性能测试的特殊性，因此在整个测试过程中，会遇到很多导致整个性能测试失败的风险。 2.2.3 评估测试和性能管理方案的规划实施q 测试用例的建立在性能评估的规划阶段，通过把以文档形式所指定的关键业务转化为实际可实施的测试用例，同时分配所采集的业务数据。q 测试场景的设置把关键业务的分布转化为评估测试的具体实施设置。q 环境配置和系统就绪在实施的开始之前，有必要保证被测应用系统是可用和经历了功能和稳定性测试的，同时功能支持必须贯穿在整个可能影响测试实施的过程。q 测试实施和性能监控按指定的流程事实评估测试，并根据关键业务对整个应用系统的影响和已有的性能参照点，在评估测试当时进行实时的性能监控。q 实时预警和被测试系统的避险针对在线系统的特定，在对被测试系统实施评估时必须有严格的实时预警和保护的自动控制，一旦被测试应用有异常的趋势和可能，必须有及时的避险机制。2.3 工作目标 构建与实际环境相匹配的基础数据环境 根据系统性能需求设计性能测试方案，定义业务模型及测试场景 执行性能测试，获取参测系统的各项性能指标 对比各参测系统的性能指标，制作综合评测报告，为评测系统性能及性能优化提供参考依据。 检验系统上线前，程序是否有大的并发漏洞，和性能瓶颈3. 测试环境3.1 测试环境拓扑图第一阶段测试采用挡板程序，交易不发送到AS400和V+：详细信息如下图：3.2 测试环境配置本次测试环境都是单机模式，和真实环境有区别，生产环境是双机；服务器类型IP地址硬件 操作系统信息应用软件信息CPU内存存储操作系统版本应用软件版本WebLogic10.31.102.114 * 2 GHz16Gb80GbRedHat Linux AS4JDKj2sdk1.4.2_weblogic8.xOracle Client 10g Release 10.2.0.210.31.102.102 * 2 GHz16Gb80GbRedHat Linux AS 4JDKj2sdk1.4.2_weblogic8.xOracle Client 10g Release 10.2.0.2Web服务器10.39.100.102 * 2 GHz16Gb80GbRedHat Linux AS 410.39.100.112 * 2 GHz16Gb80GbRedHat Linux AS 4数据库服务器10.31.22.27/kissstg8 * 3.5 GHz32Gb160GbAIX5.3.0Oracle 10g Server10.2.0.2IST服务器4 * 1.6GHz16Gb80Gb AIX5.3.010.37.174.18PACES-KISS1.5.2 10.37.174.19 Oracle Client 10g Release10.2.0.23.3 测试工具及监控工具部署测试工具 采用Loadrunner8.1， 数据库监控采用I3，系统资源监控采用OPVM。具体信息如下：工具名称许可证要求IP地址服务器配置要求操作系统要求应用软件信息CPU内存存储操作系统版本应用软件版本HP LoadRunner支持Web协议和socket协议10.31.180.104 * 2 GHz8Gb160GbWindows 2003 Enterprise Edition SP1LoadRunner Controller8.1N/A10.31.180.11/132 * 2 GHz4Gb80GbWindows 2003 Enterprise Edition SP1LoadRunner Load Generator8.1I3Oracle监控http:/i3fp-:20720/index.html OVPM系统监控:8080/OVPM/PMLogin.jsp?authenticate=44. 测试场景分析XX系统上线后所面临的性能压力的来源和类别，并且通过分析历史交易数据来确定各种性能在整个系统压力所占比例。例如确定前台应用子系统的业务类别和并发比例，后台自动批处理的数据数量和类别等。最终目的是建立一个能够逼真模拟帐户管理系统实际运行场景的业务模型。选择如下交易类型：l ATM查询l ATM取现l CDM存现l POS消费l 查询协议l 查询状态l 更新协议l 更新状态l 修改重置密码u 验证密码4.1 基准测试场景基准测试场景用来验证系统功能完整性和可用性，以及测试脚本的可重复性：序号功能名称功能点 并发循环次数操作间隔循环间隔(ThinkTime)1ISTATM查询15502ATM取现15503CDM存现15504POS消费15505ESB修改重置密码15506验证密码15507KISS查询协议15508查询状态15509更新协议1550合计更新状态15504.2 单交易场景 单交易测试场景主要是为了检验各功能模块是否有严重的性能障碍，以及检验各自交易单独的性能处理能力的最大值：序号功能名称场景子序号并发人数循环时间1ATM查询1305010020015分钟2ATM取现2305010020015分钟3CDM存现3305010020015分钟4POS消费4305010020015分钟5查询协议5305010020015分钟6查询状态6305010020015分钟7更新协议7305010020015分钟8跟新状态8305010020015分钟9修改重置密码9305010020015分钟10验证密码10305010020015分钟11合计用户调度方式:采用每秒钟增加5个用户，场景结束时每秒钟退出5个用户。每笔交易间隔时间5秒，即设置think time时间；4.3 单系统场景分别执行经过Proxy程序对IST测测试，通过ESB的测试场景和KISS应用的测试场景：序号功能名称功能点并发操作间隔循环间隔(ThinkTime)1ISTATM查询10255050ATM取现10255050CDM存现10255050POS消费102550502ESB修改重置密码255010050验证密码2550100503KISS查询协议10255050合计查询状态10255050更新协议10255050更新状态102550504.4 疲劳测试场景采用100用户并发，持续执行8小时。序号功能名称功能点所占比例循环次数操作间隔执行时间(ThinkTime)1ISTATM查询15%158小时2ATM取现10%158小时3CDM存现8%158小时4POS消费20%158小时5ESB查询协议4%158小时6查询状态4%158小时7更新协议2%158小时8更新状态2%158小时9KISS修改重置密码5%158小时10验证密码30%158小时合计4.5 混合交易场景按照分析的业务模型，对不同交易按照一定比例，分别执行不同压力的下的测试场景：序号功能名称功能点所占比例并发操作间隔循环间隔50100150200(ThinkTime)1ISTATM查询15%502ATM取现10%503CDM存现8%504POS消费20%505KISS查询协议4%506查询状态4%507更新协议2%508更新状态2%509ESB修改重置密码5%5010验证密码30%50合计5. 角色和职责部门和角色职责人员测试人员监督项目执行过程和执行结果，推进和执行质量保障体系工作流程，对项目中重大问题进行决策，协调项目所需的软硬件资源和人力资源。搭建测试开发环境,测试数据准备、被测系统（生产环境）的数据备份和清除、并提供技术支持和配合，解决测试过程中出现的各种技术问题开发人员同测试项目进行沟通，解决应用程序出现的各种问题，协调相关技术人员。性能测试专家需求调研分析，参与设计测试模型和方案，指导测试工程师开展工作；对测试中的问题进行分析和定位，协调组织整个性能测试过程，制定测试计划和方案；负责对测试案例的业务流程进行指导、评审和确认。测试范围的指定，测试需求确认；性能测试工程师进行测试准备和测试执行工作数据库专家协助解决数据库相关问题6. 性能测试总体报告XX系统第一阶段性能测试，共执行了85个场景，其中包括单业务场景，混合业务场景，单系统场景，和疲劳测试场景；IST系统在目前硬件环境和数据环境下，最大吞吐量TPS达到10个，最大并发用户数达到200个，当用户并发100个时，系统交易响应时间3秒左右。下一章会有详细介绍；系统在压力测试过程中主要是IST系统CPU利用率过高，当并发达到100时，系统CPU利用率就达到80%，其他指标正常；另外数据库服务器主要表现为IO过高，持续压力半小时系统IO就维持在100%，导致不能及时响应，出现交易失败，压力测试过程中，交易成功率一直在98%以上；分别从单业务场景和混合业务场景对系统性能状况做详细的分析；6.1 单业务场景性能分析6.1.1 KISS系统交易分析最大并发用户数为100，响应时间均在1秒以内，查询客户协议交易响应时间最长为0.187秒，TPS值在37左右，而且还有继续提升的潜力；没有发现系统资源异常。其中查询卡状态交易有少量错误，错误返回代码 1001；编号场景名称执行时间并发用户数平均响应时间平均TPS正确率IST系统资源情况异常情况备注CPUMEMIOS_001单业务测试-查询客户协议2009-11-301000.18736.8100%正常正常正常S_002单业务测试-更新客户协议2009-11-301000.03536.6100%正常正常正常S_003单业务测试-查询卡状态2009-11-301000.03737.398%正常正常正常错误代码1001S_004单业务测试-更新卡协议2009-12-11000.07837.6100%正常正常正常S_005KISS(HTTP)测试场景2009-11-301000.05330.799%正常正常正常具体信息如下表：6.1.2 IST交易分析分别测试了25用户、50用户、100用户和150用户并发的场景，其中50个并发的时候平均响应时间3秒，TPS是5个；IST服务器CPU利用率在60%左右；成功率都在90%左右（和挡板程序设置有关）； 在100用户并发数据如下表内容，CPU利用率饱和、TPS为10个左右、平均响应时间6秒左右。此时系统吞吐量达到最高；编号场景名称执行时间并发用户数平均响应时间平均TPS正确率IST系统资源情况异常情况备注CPUMEMIOS_006单业务测试-ATM查询2009-12-41006.310.985%异常（备注）正常正常CPU利用率超过90%成功率和挡板程序设置有关S_007单业务测试-POS消费2009-12-41006.19.790%异常（备注）正常正常CPU利用率超过90%S_008单业务测试-ATM取现2009-12-41006.89.290%异常（备注）正常正常CPU利用率超过90%S_009IST（proxy）测试场景2009-12-41005.79.390%异常（备注）正常正常CPU利用率超过90%6.1.3 ESB交易性能分析并发用户数分别50、100、200；其中用户并发200个时，平均响应时间3秒左右，TPS为11个左右，CPU利用率平均在90%以上；IST服务器达到饱和；当并发用户超过250时，IST出现拥堵（mblook t 查看）编号场景名称执行时间并发用户数平均响应时间平均TPS正确率IST系统资源情况异常情况备注CPUMEMIOS_010单业务测试-密码验证2009-12-72003.111.2100%异常（备注）正常正常CPU利用率90%S_011单业务测试-重置密码2009-12-72003.110.8100%异常（备注）正常正常CPU利用率90%S_012ESB场景2009-12-7200100%异常（备注）正常正常CPU利用率90%数据库IO超高 表：ESB交易性能数据6.2 综合业务场景性能分析综合业务场景是本次测试的所有交易，按照业务场景模型进行一定配比组合成的测试场景，并发用户分别为50、100、150、200；具体交易和比例如下节详细表；分别对系统吞吐、交易响应时间和系统资源利用情况在不同压力下的表现进行横向和纵向的分析；6.2.1 系统吞吐量TPS分析TPS 是系统每秒交易数，衡量系统性能的重要指标；下表是不同压力下系统TPS的表现；交易名用户比例0用户50用户100用户150用户200用户ATM取现10%00.680.931.280.93ATM查询15%00.951.231.761.36POS消费25%01.351.762.372.07修改卡状态4%00.581.11.562.07修改客户协议4%00.591.11.571.94查询卡状态2%00.521.141.571.93查询客户协议2%00.661.191.541.94密码修改重置8%00.30.540.620.63密码校验30%00.921.482.042.18合计TPS06.5510.4714.3115.05 表：综合场景TPS从下图我们可以分析出，ATM取现、ATM查询和POS消费三个交易在并发用户达到150的时候，TPS值最高，用户并发在200时，吞吐量反而下降，说明这三支交易性能出现瓶颈，主要是由于IST服务器CPU资源消耗殆尽导致；密码验证和密码修改两只交易在并发150和200时变化不大，说明也基本达到饱和状态，接近系统最大处理能力；查询卡状态、查询客户协议、修改卡状态和修改客户协议四个交易的TPS随着用户数的增加一直在提高，说明这四个交易的处理能力还有很大提升空间，回顾上面单业务测试场景我们可以解释，这四个交易的TPS可以达到30个； 图：综合场景TPS分析6.2.2 交易响应时间分析通过系统不同压力下，分析每支交易的响应时间，下表是具体数据：交易名用户比例0用户50用户100用户150用户200用户ATM取现10%01.7093.0365.0988.43ATM查询15%01.7183.0435.0168.363POS消费25%01.8513.1665.3738.607修改卡状态4%00.1120.0540.0590.071修改客户协议4%00.0890.0510.0470.064查询卡状态2%00.1020.0440.0330.033查询客户协议2%00.0660.0390.0340.041密码修改重置8%02.6032.6542.9232.946密码校验30%02.7232.882.942.98 表：综合场景响应时间数据从下图我们可以分析出，ATM取现、ATM查询和POS消费三个交易随着并发压力的增加，响应时间也基本线性增长，其中在并发用户在100个时，响应时间基本在3秒左右，当用户达到200时，响应时间接近9秒 ；说明这三支交易性能出现瓶颈，并且对IST服务器资源依赖性比较强;密码验证和密码修改两只交易在并发150和200时响应时间变化不大；查询卡状态、查询客户协议、修改卡状态和修改客户协议四个交易的TPS随着用户数的增加也没有太大变化，说明同样验证这四个交易的处理能力还有很大提升空间， 图：综合场景响应时间分析6.2.3 系统资源分析u IST服务器首先分析一下IST服务器主要资料使用情况，CPU、MEM和IO在不同压力下的表现；数据如下表：IST 服务器050用户100用户150用户200用户CPU035%68%89%95%MEM040%45%50%52%IO05%8%10%10%从下图我们可以看出，IST服务器随着压力的增大MEM和IO变化很小，而CPU利用率增长很快，当并发用户达到100时，CPU利用率就接近70%，并发达到200时，CPU就达到饱和，根据经验CPU超过80%，系统性能就会下降。 图：IST服务器资料通过对IST服务器的分析，我们发现主要瓶颈在的资源上。u 数据库服务器在测试过程中通过监控，数据库服务器的资料利用情况如下表：数据库 服务器050用户100用户150用户200用户CPU03%6%8%9%MEM040%44%46%52%IO051%78%93%100%通过下图可以看出，数据库服务器的利用率很低，不超过，内存的情况一般也维持在左右，的变化非常明显，随着压力的增加，系统不断增加，并且持续维持在； 图：数据库资源分析通过对数据库服务器的分析，主要瓶颈在系统上，在大压力下利用率会持续。7. 问题和建议 在测试过程中主要发现以下几个问题，并给出了初步建议。7.1 问题一 当并发压力用户100以上时IST服务器（10.37.174.18）CPU利用率就会持续很高，平均超过80%，监控数据如下图所示：建议：本次测试服务器为4 * 1.6GHz，想继续提高系统性能，主要方法有增加数量，提供主频，或者系统集群部分；另外也可以考虑修改应用程序，提高应用程序本身的效率；减少单位进程的资源的消耗；7.2 问题二根据目前测试环境IST硬件配置情况， 启动进程（）个数，也会影响到系统性能，下图是测试过程中并发用户，初始的进程是个，此时的维持在左右；当进程数启动个时，发现逐步提升，最终维持的； 建议：测试环境级别硬件，启动SHC进程在6-8个比较合理，使系统性能达到最大化。过少会导致IST拥堵，过多会消耗更多的系统资源，增加系统消耗。7.3 问题三ESB初始设置 tcpip.port_max 是20，当并发请求超过个时，就会导致请求失败；建议：tcpip.port_max大于200；因为此值决定ESB支持的最大并发连接数；7.4 问题四在疲劳测试场景中，发现测试执行30分钟左右出现ESB交易用户fail的情况；初步判断，由于ESB是短连接，此时数据库系统IO持续100%，导致不能及时得到响应（timeout 10秒），最后导致收不到返回报文的错误；建议：提供数据库处理性能；优化数据库分区；7.5 问题五 当系统持续压力的时候，出现数据库IO饱和，主要原因是SHCLOG 导致，建议：将kissidx01.dbf文件分区存储。或者提高物理存储设备的IO效率。8. 附录第 25 页 共 25 页IST性能测试报告 张良友