金融统计系统与前置系统性能测试情况报告——0418最终版.doc

中国金融电子化公司测试报告 金融统计系统与前置系统性能测试报告中国金融电子化公司金融统计系统与前置系统性能测试报告委托单位中国人民银行检测单位中国金融电子化公司测评中心检测类别内部测试审 核批 准文档编号FISM-测试报告-20110418时 间2011-04-18目录1、概述31.1背景31.2测试目标31.3版本修改原因31.4测试依据和标准42、测试环境42.1硬件环境42.2软件环境52.3环境差异说明53、接收被测试产品64、测试测试分析64.1性能需求64.2测试功能点74.2测试场景85、测试结果及分析125.1金融统计系统125.2前置系统175.3金融统计与前置系统混合场景315.4环境能优化说明（需要开发编写）346、测试结论及建议356.1测试结论356.2建议376.3后续工作387、测试人员388、附件398.1附件1 问题缺陷列表398.2附件2 缺陷严重级别分类（Severity）391、概述1.1背景由于金融统计系统与前置系统是总行统计司的重要业务系统，系统的正常运行也关系到民生，近几年统计数据的大量增加导致系统的压力已日渐增大，在这种情况下需要对统计系统进行性能测试是十分必要的。1.2测试目标本次测试的目标是，在灾备环境中对金融统计系统与前置系统进行性能测试，客观、公正评估系统是否能够满足实际业务性能要求，以及为性能调优进行技术支持。此次测试的具体目标为：1. 测试夜间委托文件集（DB出表）在规定时间内所生成的报表数量；2. 测试采集过程中清除临时库时间是否满足用户要求；3. 对于前期性能测试问题进行验证；4. 前置系统在多应用环境中上线前的评估。1.3版本修改原因1.3.1软件版本修改原因1）金融统计系统：主要进行了DB夜间出表的性能调优，其他方面未做修改，以下为修改内容：将参数表中代表夜间报表生成方式、代码为95的变量修改为DB出表方式，同时优化DB出表程序，优化主要调整以下内容：1.增加queryDataFromDb2方法预先获取报表查询中需要的所有SQL语句（SQL语句格式为：select KEY, FVALUE from TABLENAME where DDATE=? and SBUSINESS=? and SSECTCODE=? and SAREACODE=? and SSUBJECTID=? and SATTRIBUTECODE=? and SCURRNUMBERID=? and SFREQCODE=? ）,并将SQL语句进行缓存。2.增加queryValueMap方法将第一步缓存中单个SQL进行UNION，批量提交到数据库中执行返回结果。3.修改queryDataFromDb方法，直接从第2步返回结果中获取数据。本次升级，涉及到的类包括：ReportTaskDbMgrServiceImpl(DB出表任务执行类)、ReportTaskDbDAOImpl(DB出表数据访问类)。本次升级，只涉及到DB出表功能代码调整，不对生产环境参数进行调整。本次修改只针对DB出表功能有影响，不影响其他模块的正常运行。2）前置系统：由于此系统处在调优过程中，没有提供软件最终修改原因及分析。1.3.2基础软件配置修改原因没有对基础软件配置进行修改。1.4测试依据和标准1. 金融统计监测系统-变更说明2. GB/T 17544 信息技术 软件包 质量要求和测试3. fism(20110411).zip：金融统计系统应用部署包4. fismps(20110411).zip：金融统计前置应用部署包2、测试环境2.1硬件环境2.1.1总行环境编号类型硬件配置数量1应用服务器IBMP55A3, 4颗1.9GPOWER5CPU，8GB 内存32数据库服务器HP Superdome, 8C2核1.6G CPU，48GB 内存13WEB服务器HP DL580、4C8核2.6G CPU、8G内存12.1.2实际测试环境编号类型硬件配置数量1应用服务器SUN T5220 4C2核 1.16Gcpu, 16GB内存62数据库服务器HP superdome,24C2核1.6cpu，147GB内存13WEB服务器（未启用）HP DL580，4C4核2.13G CPU、8G12.2软件环境2.2.1总行环境软件名称版本号套数功 能IBM DB2 Server8.21数据库服务器HPUX11.231数据库服务器AIX5300-53WAS应用服务器IBM WebSphere Application Server 6.03WAS应用服务器2.2.2实际测试环境软件名称版本号套数功 能HPUX 11.231数据库服务器IBM DB2 Server9.71数据库服务器Solaris 106WAS应用服务器IBM WebSphere Application Server 6.16WAS应用服务器IBM DB2 client 9.76WAS应用服务器Suse Linux enterprise server 104Web服务器IBM IHS Server6.14Web服务器2.3环境差异说明根据总行环境与实际测试环境进行对比差异如下：1应用服务器中间件差异：IBM WebSphere总行生产环境版本版本为6.0，实际测试环境版本为6.1。2数据库服务器软件版本差异：IBM DB2 Server总行生产环境版本为8.2，实际测试环境版本为9.7。3应用硬件差异：总行生产环境CPU4颗1.9G、内存8GB，实际测试环境CPU4C2核1.16G、内存16GB，根据对比实际测试环境的硬件配置是总行生产环境硬件配置的两倍。4数据库用硬件差异：总行生产环境CPU8C2核1.6G、内存48GB，实际测试环境CPU24C2核1.6G、内存147GB，根据对比实际测试环境的硬件配置是总行生产环境硬件配置的三倍。3、接收被测试产品1. fism(20110411).zip：金融统计系统应用部署包2. fismps(20110411).zip：金融统计前置应用部署包4、测试测试分析4.1性能需求4.1.1金融统计系统业务模块并发用户数占比并发用户数响应时间平均数据量DB出表30%45没有具体要求1张报表数据采集3%5没有具体要求1个IJ文件汇总文件集32%48没有具体要求1个汇总文件集综合查询35%53没有具体要求1000条4.1.2前置系统业务量分析如下：功能名称高峰业务量（笔/天）日常业务量（笔/天）业务量年增长率%高峰时点说明备注加载到临时表1亿1000万20%/每月4日和10日数据转换1亿1000万20%/每月4日和10日生成IJ文件3000万300万20%/每月4日和10日数据核对（按表单）150030020%/每月4日和10日数据核对（按指标）150030020%/每月4日和10日对照关系（一对多）导入10万1万20%/每月4日和10日业务实体数据量分析如下：实体名称上线时的数据量1年后的数据量备注14位机构信息20万25万从机构系统导入14位机构的统计数据012亿对照关系（一对多）导入030万转换后统计数据03亿用户数如下：子系统名称（或主要功能名称）最大并发用户数（个/分钟或秒单位时间）最大在线用户数（个/分钟或秒单位时间）加载到临时表10个/分钟50个/分钟数据转换10个/分钟50个/分钟生成IJ文件10个/分钟50个/分钟数据核对（按指标）10个/分钟50个/分钟对照关系（一对多）导入10个/分钟50个/分钟处理时间要求如下：功能名称并发数系统处理速度查询的记录数备注加载到临时表500条/秒500条/秒数据转换500条/秒500条/秒生成IJ文件100条/秒100条/秒数据核对（按指标）10个并发/分钟60秒10000对照关系（一对多）导入20条/秒20条/秒4.2测试功能点根据性能需求并与开发沟通交流得出以下功能点进行测试：4.1.1金融统计性能测试点编号测试点描述1夜间DB出表测试在规定的8小时内系统生成报表数量，是否能够满足实际业务需求。2日常业务DB出表模拟日常业务流程，其中业务包括数据采集、汇总、综合查询、DB出表，测试是否满足业务要求。3删除临时表数据报送数据，系统进行删除临时表操作，测试删除临时库数据时间是否满足业务要求。140万（删除时间在5分钟之内）。4.1.2前置系统性能测试点编号性能测试点1加载到临时表2数据转换3生成IJ文件4数据指标核对5机构关系（一对多）导入6综合场景4.1.3统计与前置系统混合测试编号性能测试点1日常业务DB出表与前置系统混合场景并行4.2测试场景4.2.1金融统计系统4.2.1.1夜间DB出表场景场景名称夜间db出表场景场景编号Jrtj-001-001系统处理方式6台server每台40秒调度一次，取100条报表任务，每个任务提交一个线程。当任务完成时再取下100条任务。使用数据总行报表数据(7万张)操作一次性提交测试重点本场景测试重点在于监控数据库的性能情况。期望结果7万张报表应在8小时内正确处理，数据库服务器与应用服务器各项指标不能超过90%。监控指标重点监控：数据库服务器cpu、内存、磁盘读写情况。其他监控指标：1应用服务器cpu、内存、磁盘读写情况。4.2.1.2日常业务DB出表场景场景名称日常业务DB出表场景场景编号Jrtj-001-002系统处理方式用户在报表生成页面选择报表后添加db生成任务，任务由调度程序40秒调度执行，同时进行数据采集、汇总、综合查询。使用数据报表数据：45张；采集数据：5个ij文件；汇总数据：48个汇总文件集；综合查询：53个并发查询。操作持续4小时测试重点本场景测试重点在于监控数据库服务器与应用服务器的性能情况，另外监控数据采集、汇总、综合查询业务正确性。期望结果所有业务都能正确处理，各服务器资源指标不能超过80%。监控指标重点监控：数据库服务器、应用服务器cpu、内存、磁盘读写情况。4.2.1.3删除临时表数据场景场景名称删除临时表数据场景场景编号Jrtj-001-003系统处理方式数据重报时先删除临时表的数据，根据机构类直接删除，不再关联完备性表。使用数据工商银行30万、农业银行36万、邮储银行21万、华夏银行6万、中国农业发展银行9万。操作一次性提交五个数据迭代3次。测试重点监控数据库各项性能指标，监控任务完成时间。期望结果每个文件删除临时库时间不能超过5分钟，各项业务操作都能正确实现。监控指标重点监控：数据库服务器、应用服务器cpu、内存、磁盘读写情况。4.2.2前置系统4.2.2.1加载到临时表与数据转换场景场景名称加载到临时表与数据转换场景场景编号Jrtj-001-004系统处理方式25家全国性银行使用单独的队列，最多允许10个队列同时进行任务。使用数据分别报送1000万200万、20万、3万、3000、300数据沾满10个列队。操作占用所有队列,持续1小时测试重点监控数据库各项性能指标，记录加载到临时库时间和数据转换时间。 期望结果数据库与应用服务器性能指标不能超过80%,并且各项业务均能执行正确。监控指标重点监控：数据库服务器、应用服务器cpu、内存、磁盘读写情况。4.2.2.2生成IJ文件场景场景名称生成IJ文件场景场景编号Jrtj-001-005系统处理方式根据转换后的11位机构数据生成对应的IJ文件10个队列。使用数据分别生成1000万200万、20万、3万、3000、300数据沾满10个列队。操作占用所有队列,持续1小时。测试重点监控数据库各项性能指标，记录IJ文件生成时间。 期望结果数据库与应用服务器性能指标不能超过80%,并且各项业务均能执行正确。监控指标重点监控：数据库服务器、应用服务器cpu、内存、磁盘读写情况。4.2.2.3数据指标核对场景场景名称数据指标核对场景场景编号Jrtj-001-006系统处理方式系统转换后的11位机构数据和fism系统的机构数据进行比对，通过excel导出功能导出,供用户下载后查询。使用数据查询条件结果为10000条。操作并发查询数为2、4、8持续时间为1小时测试重点监控数据库各项性能指标。期望结果数据库与应用服务器性能指标不能超过80%,并且各项业务均能执行正确。监控指标重点监控：数据库服务器、应用服务器cpu、内存、磁盘读写情况。4.2.2.4机构关系（一对多）导入场景场景名称机构关系（一对多）导入场景场景编号Jrtj-001-007系统处理方式通过excel模板把用户定义好的机构关系上传。使用数据每个文件两万条数据。操作并发人数为5，持续一小时。测试重点监控数据库各项性能指标。期望结果数据库与应用服务器性能指标不能超过80%,并且各项业务均能执行正确。监控指标重点监控：数据库服务器、应用服务器cpu、内存、磁盘读写情况。4.2.2.5前置综合场景场景名称前置综合场景场景编号Jrtj-001-008系统处理方式与机构关系（一对多）导入、数据指标核对、生成IJ文件、加载到临时表与数据转换相同。使用数据机构关系（一对多）导入、数据指标核对、生成IJ文件、加载到临时表与数据转换相同数据相同。操作并发人数为5，持续一小时。测试重点监控数据库各项性能指标。期望结果数据库与应用服务器性能指标不能超过80%,并且各项业务均能执行正确。监控指标重点监控：数据库服务器、应用服务器cpu、内存、磁盘读写情况。4.2.3统计与前置系统混合测试统计与前置系统混合场景场景名称统计与前置系统混合场景场景编号Jrtj-001-009系统处理方式前置综合场景与日常业务DB出表场景一并执行。使用数据使用前置综合场景与日常业务DB出表场景数据。操作使用日常业务DB出表场景与前置综合场景同时进行测试。测试重点监控数据库各项性能指标。期望结果数据库与应用服务器性能指标不能超过80%,并且各项业务均能执行正确。监控指标重点监控：数据库服务器、应用服务器cpu、内存、磁盘读写情况。5、测试结果及分析5.1金融统计系统5.1.1夜间DB出表场景夜间DB出表目前运行的结果，报表共耗时2小时18分2小时30分，共生成69561报表，生成速度为0.12秒/张，DB服务器CPU平均占用率约为6.6%9.4%，最高占用率为23%28%。报表批量生成时系统资源统计：从上图中可以看出：DB服务器CPU平均占用率比较正常。结果分析：经分析，夜间批量DB出表满足8小时内完成7万张报表要求并且各项性能指标正常，但考虑到实际测环境与总行成产环境差距较大，不排除实际生成报表时间会长于测试环境时间。5.1.2日常业务DB出表场景测试结果：场景设定总体情况服务器资源测试场景测试业务点并发用户数交易平均响应时间（秒）交易成功率（%）CPU利用率(平均%/最高%)内存利用情况paging rate（平均/最高）日常业务DB出表场景综合查询563.562s100%数据库服务器：14.4%/33.52%数据库服务器：0.54/270.1汇总641.702s23.01%上传IJ文件780.997s100%DB出表无0.463 秒/张99.72%结果分析：汇总业务的平均响应时间为41.702秒，不管是否进行上传IJ文件的操作,从前台页面上手动执行，速度都比较慢，且成功率较低，建议优化调整。DB出表在后台数据库中运行生成，所以没有并发用户数。DB日常出表的生成速度为0.463 秒/张，根据这个速度估计，生成7万张报表的时间是9小时，时间较长，建议优化调整。日常业务DB出表的响应时间：从上图中可以看出：综合查询的平均响应时间为3.562秒；汇总的平均响应时间为41.702秒；上传IJ文件的平均响应时间为0.997秒。日常业务DB出表的处理能力：从上图中可以看出：综合查询的平均每秒事务数(TPS)为1.047，没有失败事务；汇总的平均每秒成功事务数为0.008，平均每秒失败事务数为0.025；上传IJ文件的平均每秒事务数(TPS)为0.112，没有失败事务 。日常业务DB出表的事务成功数：从上图中可以看出：综合查询的成功事务数为8027，没有失败事务；汇总的成功事务数为58，失败事务数为194；上传IJ文件的成功事务数为858，没有失败事务。日常业务DB出表的系统资源：从上图中可以看出：日常业务DB出表数据库的CPU平均占用率为14.4%，最高占用率为33.5% 。5.1.3删除临时表数据场景删除临时表数据分为按机构删除和按机构类删除两种情况。通过监控WAS后台日志得出删除临时表所耗用的时间，结果如下：AI3010000000020101231411文件，按机构删除：144s, 按机构类删除： 108s. 经分析，数据没有出现死锁，CPU占用资源正常，如图一所示：AI3030000000020101231411文件，按机构删除：148s ,按机构类删除: 90s。经分析，数据没有出现死锁，CPU占用资源正常，如图二所示：AI4010000000020101231411文件，按机构删除：45s. 按机构类删除：27s, 经分析，数据没有出现死锁，CPU占用资源正常，如图三所示：图一按机构删除按机构类删除图二按机构删除按机构类删除图三按机构删除按机构类删除结果分析：通过对系统进行大数据文件报送得出，临时库存量为9百万量级时删除138万数据用时108210秒，测试环境满足开发提出的5分钟内删除数据时间标准。另外由于测试环境服务器cpu与内存数是总行实际生产环境的三倍，这里不排除在生产环境中删除临时库速度要比实际测试速度慢的情况。5.2前置系统5.2.1加载到临时表与数据转换场景共上传了84个14位IJ文件，其中包括4个大文件，10个中文件和70个小文件。小文件的数据量是3003万条/个；中文件的数据量是200万300万条/个；大文件的数据量是1000万1380万条/个；测试结果：场景设定总体情况服务器资源测试场景测试业务点文件数目交易平均响应时间CPU利用率(平均%/最高%)内存利用情况paging rate（平均/最高）加载到临时表与数据转换场景前置系统上传IJ文件大文件4个大文件35分钟数据库服务器：2.93%/12.9%数据库服务器：0.58/282.3中文件10个中文件1分钟8分钟小文件70个小文件52秒60秒结果分析：此次测试，去掉了前置系统中14位机构数据查询功能，同时去掉了数据转换和生成IJ文件与金融统计系统的合法性关联。所以，上传IJ文件的速度较上个版本有所提升。结果是：大文件（1000万条1380万条）的处理时间为35分钟，未修改前为1小时16分，中文件（200万条300万条）的处理时间为1分钟8分钟，未修改前为46分钟，小文件的处理时间为52秒60秒。执行期间，DB的CPU平均占用率为2.93%，最高占用率为12.9%。文件的处理时间虽然满足性能需求中500条/秒的规定，但是在实际应用中去掉的功能没有经过用户确认。结果贴图： 前置系统上传IJ文件小文件的处理时间：从上图中可以看出：前置系统上传14位小数据量IJ文件（300条3万条）的处理时间为52秒60秒。前置系统上传IJ文件中文件的处理时间：从上图中可以看出：前置系统上传14位中数据量IJ文件（200万条300万条）的处理时间为1分钟8分钟。前置系统上传IJ文件大文件的处理时间：从上图中可以看出：前置系统上传14位大数据量IJ文件（1000万条1380万条）的处理时间为35分钟。前置系统上传IJ文件时系统资源占用情况：从上图中可以看出：前置系统上传14位IJ文件数据库的CPU平均占用率为2.92%，最高占用率为12.9%。5.2.2生成IJ文件场景生成IJ文件数据库服务器资源占用图： 结果分析：经分析，在生成IJ文件期间数据库服务器CPU平均占用率为5.644%，最高占用率为9.5%，资源占用正常。生成IJ文件场景测试通过更改数据库状态实现，所有没有处理能力的图。大文件（1000万条1380万条）生成IJ文件为6分钟左右，小文件生成IJ文件的时间为1秒99秒（300条3万条），中文件（200万条300万条）生成IJ文件的时间为1分钟3分钟。5.2.3数据指标核对场景测试结果：场景设定总体情况服务器资源测试场景测试业务点并发用户数交易平均响应时间（秒）交易成功率（%）CPU利用率(平均%/最高%)内存利用情况paging rate（平均/最高）数据指标核对场景前置系统数据指标核对243.431s100%数据库服务器：8.5%/22%数据库服务器：0.445/225.1483.85s100%数据库服务器：17.9%/36.7%数据库服务器：0.354/120.453966.5s100%数据库服务器：27.1%/50.8%数据库服务器：0.605/177.803结果分析：经分析，后台数据指标核对随着并发用户的增多，系统处理能力增加，平均响应时间增加，后台数据指标核对场景满足10个/分钟并发用户的性能需求。当并发用户数为96个即每台服务器上32个并发用户时，DB的CPU平均占用率为27%，最高占用率为50%，存在总行环境中达到100%的风险。结果贴图：前置系统数据指标核对并发用户为24个的平均响应时间：从上图中可以看出：后台数据指标核对24个并发用户时的平均响应时间为3.431秒。前置系统数据指标核对并发用户为24个的处理能力：从上图中可以看出：后台数据指标核对24个并发用户时的平均每秒事务数（TPS）为1.487 。前置系统数据指标核对并发用户为24个的系统资源占用： 从上图中可以看出：后台数据指标核对24个并发用户时数据库的CPU平均占用率为8.57%，最高占用率为22.039% 。前置系统数据指标核对并发用户为48个的平均响应时间：从图中可以看出：后台数据指标核对48个并发用户时的平均响应时间为3.859秒。前置系统数据指标核对并发用户为48个的处理能力：从上图中可以看出：后台数据指标核对48个并发用户时的平均每秒事务数（TPS）为2.798 。前置系统数据指标核对并发用户为48个的系统资源：从上图中可以看出：后台数据指标核对48个并发用户时数据库的CPU平均占用率为17.903%，最高占用率为36.705% 。前置系统数据指标核对并发用户为96个的响应时间： 从上图中可以看出：后台数据指标核对96个并发用户时的平均响应时间为6.508秒。前置系统数据指标核对并发用户为96个的处理能力： 从上图中可以看出：后台数据指标核对96个并发用户时的平均每秒事务数（TPS）为4.526 。前置系统数据指标核对并发用户为96个的系统资源：从上图中可以看出：后台数据指标核对96个并发用户时数据库的CPU平均占用率为27.127%，最高占用率为50.808% 。5.2.4机构关系（一对多）导入场景测试结果：场景设定总体情况服务器资源测试场景测试业务点并发用户数交易平均响应时间（秒）交易成功率（%）CPU利用率(平均%/最高%)内存利用情况paging rate（平均/最高）机构关系（一对多）导入场景前置系统机构关系（一对多）导入JDBC的连接池数目为3052.987s99.85%数据库服务器：9.337%/25.9%数据库服务器：0.822/330.021机构关系（一对多）导入场景前置系统机构关系（一对多）导入JDBC的连接池数目为30104.671s98.92%数据库服务器：17.2%/42.4%数据库服务器：0.932/296.413机构关系（一对多）导入场景前置系统机构关系（一对多）导入JDBC的连接池数目为302011.589s71.74%数据库服务器：6.79%/66%数据库服务器：0.871/186.337机构关系（一对多）导入场景前置系统机构关系（一对多）导入，JDBC的连接池数目调整为50204.644s99.57%数据库服务器：37.46%/87.59%数据库服务器：0.087/42.585结果分析：当JDBC连接池为30个，并发用户由10个增加到20个时，平均响应时间增加，后台出现找不到JDBC连接的错误，所以10个并发用户是JDBC连接池30个时系统的处理极限，此时增加JDBC的连接池个数，系统的响应时间变短，事务成功率增加。当并发用户数为20个，JDBC连接池为50个时，DB服务器的CPU平均资源占用率为37.6%，最高占用率为87.5%，此时CPU的占用率偏高。经分析，系统满足并发用户数10个/分钟的性能需求。结果贴图：前置系统机构关系（一对多）导入5个用户的响应时间：从上图中可以看出：机构关系（一对多）导入5个并发用户JDBC连接池大小为30时的平均响应时间为2.987秒。前置系统机构关系（一对多）导入5个用户的处理能力：从上图中可以看出：机构关系（一对多）导入5个并发用户JDBC连接池大小为30时的平均每秒成功事务数（TPS）为1.834，平均每秒失败事务数为0.003 。前置系统机构关系（一对多）导入5个用户的系统资源：从上图中可以看出：机构关系（一对多）导入5个并发用户JDBC连接池大小为30时数据库的平均CPU占用率为9.337%，最高CPU占用率为25.959% 。前置系统机构关系（一对多）导入10个用户的响应时间：从上图中可以看出：机构关系（一对多）导入10个并发用户数JDBC连接池大小为30时的平均响应时间为4.671秒。前置系统机构关系（一对多）导入10个用户的处理能力：从上图中可以看出：机构关系（一对多）导入10个并发用户JDBC连接池大小为30时的平均每秒成功事务数（TPS）为2.964，平均每秒失败事务数为0.032 。 前置系统机构关系（一对多）导入10个用户的系统资源：从上图中可以看出：机构关系（一对多）导入10个并发用户JDBC连接池大小为30时数据库的平均CPU占用率为17.291%，最高CPU占用率为42.484% 。 前置系统机构关系（一对多）导入20个用户JDBC poolsize 30的响应时间：从上图中可以看出：机构关系（一对多）导入20个并发用户JDBC连接池大小为30时的平均响应时间为11.589秒 。 前置系统机构关系（一对多）导入20个用户JDBC poolsize 30的处理能力：从上图中可以看出：机构关系（一对多）导入20个并发用户JDBC连接池大小为30时的平均每秒成功事务数为0.956，平均每秒失败事务数为0.377 。 前置系统机构关系（一对多）导入20个用户JDBC poolsize 30的系统资源：从上图中可以看出：机构关系（一对多）导入20个并发用户JDBC连接池大小为30时数据库的CPU平均占用率为6.794%,最高占用率为66.007%。 前置系统机构关系（一对多）导入20个用户JDBC poolsize 50的响应时间：从上图中可以看出：机构关系（一对多）导入20个并发用户JDBC连接池大小为50时的平均响应时间为3.393秒。 20个用户JDBC poolsize 50的处理能力：从上图中可以看出：机构关系（一对多）导入20个并发用户JDBC连接池大小为50时的平均每秒成功事务数为5.902，平均每秒失败事务数为0.025 。 前置系统机构关系（一对多）导入20个用户JDBC poolsize 50的系统资源：从上图中可以看出：机构关系（一对多）导入20个并发用户JDBC连接池大小为50时数据库的CPU平均占用率为37.461%，最高占用率为87.595% 。 5.2.5前置综合场景测试结果：场景设定总体情况服务器资源测试场景测试业务点并发用户数交易平均响应时间（秒）交易成功率（%）CPU利用率(平均%/最高%)内存利用情况paging rate（平均/最高）前置系统综合场景数据指标核对484.844s5.027s99.98%100%数据库服务器：31.1%35.5%/67.5%68.5%数据库服务器：0.2510.608/93.31165.3机构关系一对多305.65s5.735s98.06%98.48%IJ文件导入51千万文件1小时6分钟100%IJ文件生成51千万文件6分200万-300万1分钟100%结果分析：前置系统综合场景中，上传机构对照一对多关系每台10个用户，一共30个用户；后台数据指标核对每台16个用户，一共48个用户；上传IJ文件共82个文件，包括大文件4个，中文件10个和小文件68个；生成IJ文件通过修改数据库标志位，一共修改254条数据库记录， 大文件（1千万条）生成IJ文件为6分钟左右，小文件生成IJ文件的时间在1分钟内（200万-300万）。经分析，在综合场景中，数据库服务器的CPU占用率为31.1%35.5%，最高占用率为67.5%68.5%,CPU占用率过高，在总行环境中存在达到100%的风险，建议优化。上传IJ文件中大文件的处理时间为1小时20分，且在数据校验时发生错误机构关系（一对多）导入场景中的事务成功率为98%左右，事务成功率较低。结果贴图：贴图中导出EXCEL表示后台数据指标核对，开始上传机构对照关系表示机构关系（一对多）导入，前置系统综合场景响应时间：从上图中可以看出：前置综合场景中后台数据指标核对的平均响应时间为4.844秒；前置综合场景中机构关系（一对多）导入的平均响应时间为5.735秒。前置系统综合场景处理能力：从上图中可以看出：前置综合场景中后台数据指标核对的平均每秒事务数（TPS）为2.169 ；前置综合场景中机构关系（一对多）导入的平均每秒成功事务数（TPS）为2.531 平均每秒失败事务数为0.05 。前置系统综合场景服务器资源占用：从上图中可以看出：前置综合场景数据库的CPU平均占用率为31.1%，最高占用率为68.54%。前置系统综合场景事务成功率：从上图中可以看出：前置综合场景中，后台指标核对成功的事务总数为8439，失败的事务数为1，机构关系（一对多）导入成功的事务总数为10265，失败的事务数为158。前置系统综合场景上传IJ文件：从上图中可以看出：上传大数据量IJ文件（1千万数据）的时间是1小时18分，且在数据校验阶段出错。5.3金融统计与前置系统混合场景测试结果：场景设定总体情况服务器资源测试场景测试业务点并发用户数交易平均响应时间（秒）交易成功率（%）CPU利用率(平均%/最高%)内存利用情况Paging rate（平均/最高）金融统计与前置系统混合场景前置系统上传14位IJ文件51千万文件1小时6分钟100%数据库服务器：28.5%/58.7%数据库服务器：0.457/201.5前置系统生成IJ文件51千万文件6分200万-300万1分钟100%前置系统一对多机构158.3s98.1%前置系统后台数据指标核对2413.3s98.8%金融统计系统汇总644.8s27.3%金融统计系统综合查询5412.6s89%金融统计系统上传11位IJ文件783.389s89.4%金融统计系统DB出表240.229秒/张98.97%结果分析：在前置系统与金融统计系统混合场景中，汇总业务的交易成功率仅为27%，其他业务的成功率也都偏低上传IJ文件时间较长，大文件在因为数据校验出错而没有进行数据转换数据库服务器的CPU平均占用率为28.5%,最高占用率为58.7%，在总行环境中存在占用率达到100%的风险。当金融统计系统的并发用户数不变，前置系统的并发用户增加一倍，DB数据库的CPU平均占用率达到47.7%，最高占用率达到81.4%。服务器达到几近瘫痪的极限。结果贴图：混合场景响应时间： 从上图中可以看出：后台数据指标核对的平均响应时间为13.337秒；综合查询的平均响应时间为12.625秒；汇总的平均响应时间为44.822秒；机构关系（一对多）导入的平均响应时间为8.308秒； 金融统计系统上传11位IJ文件的平均响应时间为3.389秒。混合场景处理能力： 从上图中可以看出：后台数据指标核对的平均每秒成功事务数为1.252，平均每秒失败事务数为0.015；综合查询的平均每秒成功事务数为0.396，平均每秒失败事务数为0.049；汇总的平均每秒成功事务数为0.019，平均每秒失败事务数为0.027；机构关系（一对多）导入的平均每秒成功事务数为1.358，平均每秒失败事务数为0.025； 金融统计系统上传11位IJ文件的平均每秒成功事务数为0.101，平均每秒失败事务数为0.012 。混合场景系统资源： 从上图中可以看出：金融统计与前置系统混合场景中，数据库的CPU平均占用率为28.672%，最高占用率为58.71% 。5.4环境能优化说明（需要开发编写）经过测试对测试环境进行了优化系统性能明显得到改善，以下是对性能优化汇总情况。现开发部门还未提出优化说明服务器名称参数名称修改前参数值修改后参数值用途描述6、测试结论及建议6.1测试结论在测试环境中，金电公司测试中心对金融统计系统V2011.04.11.12.00版本与前置系统V2011.04.11.12.00版本进行了内部性能测试但测试环境与总行生产环境存在较大差距，由此得出的测试结论存在一定的风险。以下为各个场景的测试结论：6.1.1金融统计系统1）夜间DB出表夜间批量DB出表满足8小时内完成7万张报表要求并且各项性能指标正常，但考虑到实际测环境与总行成产环境差距较大，不排除实际生成报表时间会长于测试环境时间。2）日常业务DB出表由测试结果分析可知，汇总业务的平均响应时间为41.702s，不管是否进行上传IJ文件的操作,从前台页面上手动执行，速度都比较慢，且成功率较低，建议优化调整。DB日常出表的生成速度为0.463 秒/张，根据这个速度估计，生成7万张报表的时间是9小时，时间较长，建议优化调整。3）删除临时表数据通过对系统进行大数据文件报送得出，临时库存量为9百万量级时删除138万数据用时108210秒，测试环境满足开发提出的5分钟内删除数据的时间要求。另外由于测试环境服务器cpu与内存数是总行实际生产环境的三倍，这里不排除在生产环境中删除临时库速可能会比实际测试速度要慢。6.1.2前置系统1）加载到临时表与数据转换由于测试时发现前置系统的上传IJ文件功能存在处理时间很慢的情况，约在1小时30分，并发报送大数据量文件（1千万条数据）时会出现业务失败情况，为了解决执行时间较慢问题，所以去掉了前置系统中14位机构数据转移至临时表的步骤，同时还去掉了数据转换和生成IJ文件与金融统计系统的合法性关联。所以，上传IJ文件的速度较上个版本有所提升。结果是：大文件（1000万1380万）的处理时间为35分钟，中文件的处理时间为1分钟8分钟，小文件的处理时间为52秒60秒。执行期间，DB的CPU平均占用率为2.93%，最高占用率为12.9%。文件的处理时间虽然满足性能需求中500条/秒的规定，但是在实际应用中去掉的功能需要经过用户确认。2）生成IJ文件为了解决生成IJ文件执行时间较长的问题，生成IJ文件时不对i文件和j文件进行压缩，所以生成IJ文件的速度较上个版本有所提升，结果是：大文件（1000万条1380万条）生成IJ文件为6分钟左右，小文件（300条3万条）生成IJ文件的时间为1秒99秒，中文件（200万条300万条）生成IJ文件的时间为1分钟3分钟。3）数据指标核对后台数据指标核对随着并发用户的增多，系统处理能力增加，平均响应时间增加，数据指标核对场景满足10个/分钟并发用户的性能需求。当并发用户数为96个即每台服务器上32个并发用户时，DB的CPU平均占用率为27%，最高占用率为50%，由此推算，总行环境中资源利用率可能会达到100%。4）机构关系（一对多）导入并发用户由10个增加到20个时，平均响应时间增加，事务成功率降低，所以10个并发用户是JDBC连接池30个时系统的处理极限。系统满足并发用户数10个/分钟的性能需求，当并发用户数为20个，JDBC连接池为50个时，DB服务器的CPU平均资源占用率为37.6%，最高占用率为87.5%，此时CPU的占用率偏高。5）前置综合场景在综合场景中，数据库服务器的CPU占用率为31.1%35.5%，最高占用率为67.5%68.5%CPU占用率过高，由此推算，在总行环境中存在达到100%的风险。并发报送14位IJ文件（1千万条左右）时会产生业务失败情况。机构关系（一对多）导入场景中的事务成功率为98%左右，事务成功率较低。8.1.3金融统计与前置系统混合场景在前置系统与金融统计系统混合场景中，汇总业务的交易成功率仅为27%，其他业务的成功率也都偏低。DB的CPU平均占用率为28.5%,最高占用率为58.7%，在总行环境中存在占用率达到100%的风险。6.2建议1）由于夜间批量DB出表数据量庞大，并且实际测试环境与总行生产环境差异较大，建议加强夜间批量DB出表的监控，以保证总行业务能正常稳定运行。2）日常业务DB出表建议提高汇总提交任务响应速度和日常报表的生成速度。3）并发报送多个14位IJ文件（1千万条左右）时会出现业务失败情况，建议修改或进行业务控制。3）为缩短前置系统上传14位IJ文件的数据校验阶段的执行时间，取消了校验后把14位机构数据转移至临时表的步骤，导致14位数据查询功能不可用，需要与用户确认。4）为缩短前置系统上传14位IJ文件数据转换阶段的执行时间，取消了合法性的关联，导致无论用户报送数据是否正确，系统都能够进行转换，需要与用户确认。5）为缩短前置系统生成14位IJ文件阶段的执行时间，取消了合法性的关联，导致无论用户报送的数据是否正确，系统都进行IJ文件生成，并且生成IJ文件不对i文件和j文件进行压缩，导致系统无法下载生成的后的IJ文件，需要与用户确认。6）数据指标核对虽然现阶段满足10个/分钟查询业务要求，但随着业务的增加，系统有可能出